Kickstarter Mupen64plus -> OUYA

[apersonthinks]

Paul of paulscode.com has recently started a kickstarter to help get Mupen64plus AE ported to the OUYA so it will be available at the time of the OUYA's launch. And once everything is settled, work will be done to bring the android-edition changes upstream to the main mupen64plus project so a new optimized pandora port can be made (with gles2n64 AND gles2rice plugins).


http://www.kickstarter.com/projects/1114140022/mupen64plus-ouya-nintendo-64-emulator

 

[WizardStan]

On the one hand, I imagine this is so totally unnecessary that it shouldn't even require the $800 being asked for: what porting that would be required should be relatively straightforward. Even if Paul doesn't get the $800 I can't see that preventing him (or maybe someone else) from doing what needs to be done.


On the other hand, I also imagine that there'll be a LOT of people that will pledge to it just because of fanboy clashing.


On the gripping hand, my sense of capitalism applauds him. I hope he makes a lot of money.

 

[skeezix]

yeah. looks like a money grab.. but hey, why shouldn't he make a buck? Are we all just jealous we didn't get $$ for doing it?..


.... no, most folks frown on $$ for other peoples work, where they did most of the work. Its like saying 'look, I ported MAME over the weekend, let me sell it on Android Market for $5, har har!", when of course, the list of MAME contributors woudl be in the thousands, and manmy years of man-work done to build it; drive-by porters trying to make a buck on other peoples work is lame.


But if someone does a good port, works hard on it.. why not? Like Kyle when he ported Wesnoth to iOS.. he got clearance from everyone, and did a good honest hard working port, and charges for it with everyones blessing; well done, nice and on the level.


But doing it as a KS.. what if he gets $10,000? I hope he kicks some back to the original devs who actually made the app


Looks like he just wants some cash to pay for his ouya and other stuff, so, wish him luck! If he's already spent piles of time making it work on Android before, its probably almost no work for ouya, but he's done his time, so okay, seems legit.


jeff

 

[apersonthinks]

The $800 is needed to purchase one dev kit. They are 8 times more expensive than what the standard version will cost. (and they ship in january, not whenever the standard version is released)

 

[TrashyMG]

You need to pay that much for an Ouya dev kit? Almost seems cheaper to get a genericTegra 3 dev board or an Asus Transformer which has the same SOC.

 

[Exophase]

Is there any reason why you need an Ouya devkit (whatever that actually offers) to do this as opposed to just an Ouya? He already has the thing ported on Android, what can really be needed here?


I don't think there's anything wrong with this per se, especially compared to the myriad of Android emulator ports that are charging - this is a small and modest goal coming from someone who AFAIK has been doing it for free, has a pragmatic justification behind the cost, and is very upfront with where it came from and who deserves credit. If there's any remark I'd give it's that it all feels kind of frivolous. The needed amount is so low that it could probably have been easily raised by traditional direct donation methods. That way it wouldn't have to go through the whole KS rigmarole. Like the pretty amateurish cover video with an especially bad static shot, the pledge tiers that range from silly to compromising and difficult to promise, and the cut Amazon and KS will get to take. Since the tiers are all pretty pointless and don't include the actual core deliverable itself people will have no real motivation to bid past the win goal so it'll probably see a lot less overshot than usual (if it reaches the goal in the first place, which it most likely will).


But I've been very impressed with the sort of opportunities KS has enabled so far so I can accept the occasional frivolity.

 

[vcoleiro1]

Paul is a member of this forum, so if you have any questions you can PM him directly

 

[Askarus]

THAT'S GREAT.


Some hope to get better N64 on Pandora.

 

[Exophase]

THAT'S GREAT.


Some hope to get better N64 on Pandora.

I don't think it'll impact the quality of the Pandora version at all. In theory if Paul really did fix game bugs as requests from pledge tiers it could make its way to the Pandora version, but I'm skeptical on how well he'll be able to deliver that. And I doubt either of the two tier slots (@ $800) will be filled.

 

[elwing]

The $800 is needed to purchase one dev kit. They are 8 times more expensive than what the standard version will cost. (and they ship in january, not whenever the standard version is released)

if he can really pulls out a good mupen64version I can't imagine ouya supporting him directly with a dev kit...

 

[ZXDunny]

On the one hand...


On the other hand...


On the gripping hand...

You sir are a man of taste and distinction in your literature and I approve most wholeheartedly.


D.

 

[PokeParadox]

Boo... I'd back it if there was a clause mentioning improving upon the Pandora port...

 

[apersonthinks]

If he's already spent piles of time making it work on Android before, its probably almost no work for ouya, but he's done his time, so okay, seems legit.

I can attest to that. I remember when just last year there was no gui and the only graphics plugin was a buggy port of gles2n64. It has come far since then and hopefully will continue to improve.

 

[paulscode]

A couple good points have been raised here that I wanted to address.


Firstly, a Pandora port of Mupen64Plus AE is currently in the works. Since a lot of it is just an extension of the first Pandora port (dynarec, gles2n64), it is important to me to be able to contribute the work we've put into the core and video plug-ins back to this project.. I expect to actually have the basic project (minus a front-end) in the repository before the OUYA dev kit arives in January. I hope to get a dedicated Pandora dev to take on the front-end, though, since the Android and OUYA front-ends will continue to sap a lot of my time for a while yet.


About the OUYA dev-kit -- the $800 is to pre-order the OUYA early (shipped January) so that I can have the application ready by the time OUYA goes live (March/ April). After that, the dev-kit is part of the OUYA console, and not an additional cost. The kickstarter is set at $800 because that is the cost of the first dev-kit, which is all I'll need to meet the delivery date of April. I don't expect funding to stop there, but that is the minimum amount needed, so that's where I set it. Additional funding (up to $5,000 or so) will be used to purchase additional OUYA dev-kits ($800 each) for other members of the dev team to help out.


If the Kickstarter funding goes higher than that (which I expect it will.. just not sure how much), then the rest will go into the donations pot for Mupen64Plus, AE (with the donations from Google Play and SlideME). The majority of that, after taxes, I donate back to various developers and projects that I have borrowed from, rewards for the more dedicated testers, and community-building projects like the artwork competition we did a while back. Most of the people listed in the credits I've pushed back support using the donations we've received, and these guy's definitely deserve the support for the awesome work they do for nothing!

 

[WizardStan]

The $800 is needed to purchase one dev kit. They are 8 times more expensive than what the standard version will cost. (and they ship in january, not whenever the standard version is released)

Ah, did not know that. He did mention a dev kit was what it was for in the kickstarter, I guess it didn't really click in my head..

If the Kickstarter funding goes higher than that (which I expect it will.. just not sure how much), then the rest will go into the donations pot for Mupen64Plus, AE (with the donations from Google Play and SlideME). The majority of that, after taxes, I donate back to various developers and projects that I have borrowed from, rewards for the more dedicated testers, and community-building projects like the artwork competition we did a while back. Most of the people listed in the credits I've pushed back support using the donations we've received, and these guy's definitely deserve the support for the awesome work they do for nothing!

Philanthropic! Here, have $5.

 

[paulscode]

the pledge tiers that range from silly to compromising and difficult to promise

I doubt either of the two tier slots (@ $800) will be filled.

I forgot to address this in my last post. I'm not sure about the silly part, but to better explain where I'm going with this, it mainly breaks down into two things:


1) GUI customizations


2) Game bug-fixes


The lower-value tiers involve either nominating one of these, or casting a vote for which of the nominations should go to the top of the priority list. There are a couple of high-dollar tiers for anyone who wants to bypass the voting process, but I don't really expect anyone except my closest friends to pledge that much anyway (I put a limit just in case I am somehow very wrong in this assumption).


In all likelyhood, what I'll end up with at the end of the day for deliverables are one GUI customization, one bug-fix, and possibly a third wildcard that may or may not fall into one of those two categories. Since a lot of folks will vote on each of them, these two or three things will definitely be something that is desired by a lot of folks. As such, they will also almost certainly be something I want and plan to implement anyway, but may have gotten burried down on the priority list.


This is just a way for folks to be part of the prioritization process. I don't see it as a bad thing.. it is a way to get more people to have a stake in the project and strengthen the community of interest. I've done creative things like this throughout the life of the project, so I don't personally see it as silly or compromising. If I were more of a control freak when it comes to the direction of the project, it probably wouldn't be as versitile, and there certainly would be fewer people interested in it.

I don't think it'll impact the quality of the Pandora version at all. In theory if Paul really did fix game bugs as requests from pledge tiers it could make its way to the Pandora version, but I'm skeptical on how well he'll be able to deliver that.

There are in fact several bug-fixes that we have done already, in both the core and gles2n64. There is no reason bugs can't be fixed (especially if they are specific to the GLES2 video plug-ins, which most are). It just takes putting the time into figuring out the cause and coming up with either a better way to do things or a workaround. As for them making it into the Pandora version, that will be easier once I have the Pandora port built into the repository (fixes will be virtually simultaneous for Pandora, Android, and OUYA).

 

[Exophase]

I read the tiers pretty thoroughly before and while I appreciate the clarification I think it was pretty clear to me.. sorry but it just feels like they're there because KS starters feel obligated to put in a whole bunch of stuff. I don't think you're doing yourself or the fanbase any real favors by letting people buy oversight on how you work on the project. You're much better off doing what actually makes sense, what benefits the most people, and what you feel like doing - not what caters to those who are willing to put up money for it.


I have a question.. how many game compatibility bugs have you fixed so far? That's an honest question, I don't know so I'm not trying to rag on you. It's just my experience that most people who are porting emulators don't fix a lot of bugs because it's not only a ton of hard work but also requires a lot of indepth knowledge and experience with the inner workings of the code and the system (and a particular knack for optimization). People with this kind of dedication are usually off making new emulators (or already making major changes/contributions to emulator cores). Not always of course; there was one person who fixed some bugs in his gpSP port. But that's my broad experience.


You did put in disclaimers that you can't guarantee anything and that you'd just try your hardest. I'd be concerned that you'd spend a ton of time trying to figure out the cause of one thing over addressing a bunch of easier things. It's pretty moot though - really hard to imagine someone donating all that money just to get a specific bug fixed in an emulator. Especially for the people who don't even know what bugs it'll have.

 

[paulscode]

I have a question.. how many game compatibility bugs have you fixed so far? That's an honest question, I don't know so I'm not trying to rag on you.

No worries, that's a great question. The answer really depends on your perspective. Do you include platform-specific issues or not.. and if so which are relevant? (OpenGL vs GLES2? Pandora vs Android? 1.5 vs 1.99.x? Jan dynarec vs June?). To give you some real numbers though (and so I don't sound like I'm skating around the question) lets assume we're talking about game compatibility bugs that existed in the pre-alpha builds of Mupen64Plus AE (closest to the source from Pandora/ official versions) which are now fixed in the latest source commits. This list is not comprehensive, but it is most of them:


1) Mario64 incorrect normals on devices without Neon


2) Mario64 missing/ flickery shadows


3) Zelda OOT freeze when entering Kakariko village


4) Zelda OOT flickering floors


5) Zelda OOT crash on Galaxy S2 and Yinlips game console


6) Zelda OOT black squares on Droid Bionic and Razr


7) Zelda MM freeze at first portal


8) Smash Bros junk graphics


9) Conkers BFD junk during circle transition


10) Dobutsu No Mori (Animal Forest) immediate crash on start-up


In theory, I could also mention numerous bugs that were resolved simply by upgrading from 1.5 to 1.99.5 or adding the GLES2 Rice video plug-in as an option.

 

[Exophase]

Core emulator issues, yeah. Not platform specific ones, or ones that got fixed by upgrading to someone else's code. It sounds like fixed a lot of stuff nonetheless, probably a lot more than most people porting emulators on Android. But just to put you on the spot a little more, I have a more specific question - have you fixed any bugs that involved carefully examining the game as it's running?


As kind of an idea, in the last day before notaz released the PCSX-reARMed version with gpu_neon he tested it in a bunch of games and gave me a bunch of bugs. Most of them were relatively obvious and simple to fix. Bugs that cause the emulator to crash are also often (but not always) not too painful. In contrast, I've had CPU bugs in emulators that are extremely subtle and took days to fix, if I ever fixed them at all. They tend to involve digging really deep into what the game is doing and trying to figure out what it's supposed to be doing instead of what it is (once figuring this out actually fixing it is usually not as bad). I know I'd never offer to fix any bug someone throws at me as a request, and that's for an emulator I wrote. I'd be even less inclined to do so for what's predominantly not my code, unless I had an enormously thorough working experience with it.


And if the game is only exhibiting the bug on some ports or some modes it's a lot easier to figure out because you can compare the two versions without having to know anything about what the game does. In my case I can roughly binary search for where the game state diverges. It's a little time consuming but I must have done it hundreds of times now.


Sure, this is all moot if someone asks for a bug that's like the ones you've handled and can handle again. But with N64 it seems like you're especially asking for it because someone could pledge $800 to try to get you to add support for a game that no HLE N64 emulator supports, like Indiana Jones and the Infernal Machine. Then you're going to be stuck spending god knows how long trying to do LLE emulation or reverse engineer the game for HLE. You said that you can't guarantee you'll get it done but you also said you'd try your hardest and keep logs of your progress and contact people.. and you could be committing yourself to something pretty serious.

 

[paulscode]

Haha, that's why I clearly stated:

IMPORTANT: there is no guarantee that I will be able to fix every bug, but I will give it my absolute best effort, I'll talk with other experienced developers about it, and provide weekly progress updates about the bug until it is solved. If I am ultimately unable to solve the chosen bug, you will have the option of choosing a different bug, until one you choose is solved.

But to answer your first question, no.. not to the level you described. That's not to say I am incapable, just that it hasn't been a priority. But if someone wants something bad enough to plop down 800 bucks, then by golly I'll give it a shot. I will absolutely give every one of these requests an honest effort, I have no problem with that. Folks who think I'm wasting time - well I'm doing this for fun, and the code is open for anyone to branch if they want to do it differently. That said, some bug-fixes (as you well described) just ain't gonna happen. If someone gets that pissed-off about it, I'd just send them their $800 back and call it a day


But thinking logically here for a second, folks who pick the bugs have no idea (or care) whether they are platform-specific, version-specific, or what. They just want to play whatever game is having problems. From that perspective, what gets picked will most likely be specific to the GLES2 or ARM pieces, since those problems most often affect areas of games that have long been working on the OpenGL x86 versions.