Search results

Did a quick compile of mupen64plus 1.99.5 bundle and extras and it appears that the glide64 plugin included in extras works. http://code.google.com/p/mupen64plus/downloads/detail?name=mupen64plus-extraplugins-src-1.99.5.tar.gz&can=2&q=

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

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.

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)

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...

on gpSP. The only game that would even accept button presses was mega man one. But it could be the goomba emulation core has changed since you tried it last.

Goomba doesn't work with most if not all games. Both zipped an unzipped games work.

You could do something where 127.0.0.1 website.com #thiswasaddedbyamanager where #thiswasaddedbyamanager is treated as a comment. The manager could read that string to determine whether it was the manager or something else that added the line.

You can delete all the non 127.0.0.1 lines. All you need is 127.0.0.1 facebookcrap.facebook.com 127.0.0.1 morefacebookcrap.facebook.com etc.

Edit /etc/hosts and put 127.0.0.1 <nameofsite.com> for each domain that needs to be blocked.

I got flash working by copying the plugin to /home/<user>/.mozilla/firefox/<profile>/plugins/

The 3D driver appears to be updated for bugfixes and thats about it. It still wont work with the *.emus

From the kernel issue tracking thread: I am going to see if I can do anything with this newer gfxsdk and if it likes the newest header.

But GLES 1.1 compatibility seems to be maintained. Otherwise the libGLES_CM lib wouldn't exist :P

Guess ill try replacing gles with gles2 next time I boot into slackware. I thought it was defined in <GLES/glext.h> but idk.

Even after I changed that to 800x480, the NES and PCE systems still insist on using the original aspect ratio.

You have to add something to the gg.sh script to tell SDL to scale to full screen. I'm thinking for the systems where scaling doesn't work, the aspect ratio is hardcoded and can't be changed without recompilation for whatever reason.

If I remember correctly, the libz thing was also an issue when I tried to compile the NGP.emu for android myself. The prefix shouldn't be an issue as it picks up the other libraries just fine. Its mainly this blasted opengl stuff that needs to be fixed. Again, whoever thought up gles was an idiot.

I often consider gb and gbc to be the same thing. And by full screen, I mean stretching the image to fill the entire screen, so no black borders exist.

Tried compiling in slackware as all my attempts with debian (even mesa GL) failed. Now in slackware, libfreetype.so complains that inflateInit2_ was not found but existed in libz. I added libz and still get the same error (Edit: the inflateInit2_ is something to do with japanese characters or...