Kickstarter Mupen64plus -> OUYA


Yes, and I've made it pretty clear that I know you can't guarantee you'll fix it. Instead you just guaranteed you'll give it everything you've got. Are you saying you actually won't do this? :p


I've also made it pretty clear that I get that people who request bug fixes won't care what the nature of the fix is:

Sure, this is all moot if someone asks for a bug that's like the ones you've handled and can handle again.

See?


But that doesn't remove the risk. And an $800 tier definitely attracts people who know that they're asking for something more serious.


But no point going on about this now, not like you can change the tiers once you've made them. Or maybe you can if there are no backers.
 
Last edited by a moderator:
I get that you get that I get... um, you get the point ;D


I could change the tiers, but I won't. I will give the problem my best effort, like I said, and I have no problem telling folks that I can't fix something if I can't. I'll just give them their cash back if they don't have something else for me to try.
 
Just to paraphrase the above conversation for those who don't want to read through it:


Exophase: You are completely insane!


paulscode: I know!


I think that about covers it :D
 
Last edited by a moderator:
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.

Hear hear! ^_^


... I'm sure to alien species out there we appear just as dangerous - short life spans, exceedingly violent as a whole, collectively insane, breed continuously and obsessively, uncontrolled and unchecked expansion, raping and laying waste to the environment for resources, etc. etc...


I'm sure they know all about us... and there is good reason it appears we are alone... what sane being would let us loose on the galaxy?
 
If any of you guys have good reward ideas, let me know. Would be nice to put in an incentive for Open Pandora users if it makes sense (even though the goal of this particular campaign is to fund some OUYA dev kits). Maybe could do some stretch goals on there for an Open Pandora front-end, in case the project gets over-funded higher than I expect it to. Extra cash could be used to support a dedicated dev to take on the Open Pandora front-end while I'm focused on the OUYA front-end.
 
Last edited by a moderator:
Port Glide Napalm to OpenGL ES. Most work will be converting assembly functions to C and porting the wrapper (Since the plugin uses the Glide API internally).
 
The latest build released last night is really amazing. 64-bit emulation is fixed so DK64 loads (still unplayable because collision detection is broken), majora's mask works, and its all open source
 
Small update: I've added an actual physical reward to the campaign. This one is for a custom Nintendo 64 controller that has been hacked to have a USB plug on the end, allowing it to be attached directly to the OUYA. I've already done one of these for my own personal use, so this is something I know I can easily deliver on). This will allow players to have the full N64 experience. It'll also have the Mupe64Plus logo on the case (for OUYA users this will be whatever logo is decided on for the OUYA app, but I can put the original Mupen64Plus logo on there or the AE logo, or whatever, if requested) The controller could probably also be used on the Open Pandora.. I'd test it on my own Pandora just to be sure, but the USB port broke on mine :(
 
Port Glide Napalm to OpenGL ES. Most work will be converting assembly functions to C and porting the wrapper (Since the plugin uses the Glide API internally).
I'm waiting for it to be officially supported by the latest version of Mupen64Plus (it broke in 1.99.5 update from what I understand.. correct me if I'm wrong about that). Richard wrote a post a while back that he was working on it. I'll follow up and see where he's at in the process.


--EDIT-- If anyone can point me to a version of Glide Napalm (modified or otherwise) that works on 1.99.5, I'll start looking into porting it to GLES.
 
Last edited by a moderator:
Is this the same thing as Glide Napalm, or no? I am familiar with Glide, but I guess I've just assumed adding the term "Napalm" was a specific version that had different compatibility. Anyway, I know I read a conversation between Richard and someone about this, but I can't seem to find it now (thought it was on Emutalk).
 
Last edited by a moderator:
Yep, that's it. I'm going to assume the version of glide in the extras package is the one we want to port to GLES, unless someone informs me otherwise.
 
Port Glide Napalm to OpenGL ES. Most work will be converting assembly functions to C and porting the wrapper (Since the plugin uses the Glide API internally).
I'm waiting for it to be officially supported by the latest version of Mupen64Plus (it broke in 1.99.5 update from what I understand.. correct me if I'm wrong about that). Richard wrote a post a while back that he was working on it. I'll follow up and see where he's at in the process.


--EDIT-- If anyone can point me to a version of Glide Napalm (modified or otherwise) that works on 1.99.5, I'll start looking into porting it to GLES.

Balrog and wahrhaft have made an attempt at porting Glide Napalm to the new API. But it's probably not stable enough for inclusion in upstream. The issue was that the original Glide Napalm plugin was 32bit only due to x86 assembly. Converting the assembly to C would make the project portable. This is currently in progress. When all of this is finished the wrapper needs to be ported to OpenGL ES.

Yep, that's it. I'm going to assume the version of glide in the extras package is the one we want to port to GLES, unless someone informs me otherwise.

This is the one. Glide64 != Glide Napalm.
 
Last edited by a moderator:
Balgrog and wahrhaft have made an attempt at porting Glide Napalm to the new API. But it's probably not stable enough for inclusion in upstream. The issue was that the original Glide Napalm plugin was 32bit only due to x86 assembly. Converting the assembly to C would make the project portable. This is currently in progress. When all of this is finished the wrapper needs to be ported to OpenGL ES.

Thanks, I'll try and keep an eye on the progress then, and when it is ready to work with the new API I'll start looking into porting it to GLES. Anyone can shoot me a PM if I miss something while I'm busy with other things.
 
I'd just like to add for lulz.. I hate, when digging through what seems to be a bug in CPU emulation and you in fact find a bug... and fix it; in turn, that fixes the game you are looking at, and then breaks a bunch of others. How can fixing the bug do that, you wonder?..


.. and thats how annoying writing emulators is :) So many times I've found out that games seem to work when you have bugs, and fixing them is the way to go, but in turn it leads to _other bugs_ that weren't originally a problem :)


Anyway, sorry to hijack :)


jeff
 
Last edited by a moderator:
I've decided to write an e-book called "A Hacker's Guide to the Nintendo 64", and provide it as an exclusive reward for Mupen64Plus AE supporters! It will cover some fun projects of various difficulty levels. Topics will include controller modifications and adaptation strategies, how to rip ROMs from your game cartridges, programming your own homebrew N64 games, and a couple arduino projects. If you're interested, please stop by the Kickstarter page and consider donating to the project if you can.
 
I wouldn't make it 'exclusive' to KS folks .. why not publish it online? ie: if its a useful resource, it'd be a shame to limit it to a few hundred/thousand people :)


jeff
 
Back
Top