Release Mupen64Plus 2.2


kumaki. there is space to specify settings info in the notes on settings column.
But there isn't...or at least I do not undestand the format.

Used Plugin, that I undestand...that is the RSP Plugin.

But there's nowhere to define what Video Plugin or what Audio Plugin you used.

Mupen Version, I understand.

Pandora Model...I understand.

SGX Driver...no idea what the hell that is.

SZ Version, I understand.

Frequency...that I also understand.

I don't mind reporting my things rioght on the Wiki...But I want to be able to put accurate, helpful info in there.

Now if someone can explain to me what goes where...

It doesn't help anyone if I'm putting info that I think is useful and helpful - but putting it in in such a way - putting wrong info in wrong places...which would then make the information useless.

So, if someone could kindly explain to us non-coder morons...what each category means...and what information goes there...and wher to find it....so that I can actually post useful info...I'd be happy to do it.

Please?

Thanks!
 
Can you provide a savestate? Because I don't have freeze anymore. I use Rice (GLES2) Plugin and have the demo running fine and I can go ingame with no issue (just a few visual artefacts here and there).
I stand corrected. Looks like the .eep and .mpk save files have to be deleted before it will work if coming from a non-fixed version.
 
SGX Driver...no idea what the hell that is.
It is only for Ghz Pandora (it is the driver version for the gpu)

Please write the plugin names in the comment column (at least I think this is the right place, please refer to the existing posts) :) .
 
Last edited by a moderator:
ohhhhh, kay....there's only two entries...and neither one has any mention in their comments space abot which video/audio plugins were used.

But if that is okay, then I guess I'll put them there.

It does make a difference on some games...for example, Dr. Mario will not work with any video plugin except for one.  All others give a graphical problem which makes the game unplayable.
 
Last edited by a moderator:
Ok, tried out the new Mupen for the first time and it crashed straight my pandora Completely, not so nice. So far I was only able to test StarFox shortly but it just crashed when tried training mode.

PLEASE add a proper config per game so I don''t have to try every possible plugin configuration to make a game work (this was my main concern by the way). Also, how can I lower the rtesolution, it's way to high for an CC Pandora, old mupen was able to render lower res (also an concern of me).

I really don't have time for going throufgh all configs. Is there a "save" plugin combination that does not crash the system? I have no clue about all of these plugins and settings, the old config worked fine.

Edit: glide plugin works for StarFox but still much slower than the old version. New Menu/launcher is confusing imho and I need touchscreen and controls to use it, VERY strange.
 
Last edited by a moderator:
Last page ptitseb said that such a config per game collection would have to be done by the community.

I think a good way to let a pandora do find good configs would be:
 

First for each Rom:

1. Get a good, very accurate software renderer (maybe even on a pc, speed doesn't really matter)

2. Let the software renderer run and take 8 screenshots (between frame 200 and 1600).

Then for each rom:

1. Start the game with each software plugin.

(2. For security Reasons: Catch a possible crash and give the crashing software plugin a non working status)

3. Measure framerate

4. Let the plugin renderer run and take 8 screenshots (between frame 200 and 1600, at the same frame when the software renderer did it).

5. Calculate difference between software renderer screenshots and the plugin screenshots.

6. Use the algorithm with the best ratio between accuary and speed. I would recommend a treshhold for speed and accuary (a black screen or 2 FPS are both bad).

How determine the accuary?

Lets say we have a pluginScreen and softwareScreenshot. 

We want to know if Pixel 100,200 is the same.

Calculate a pixelblock of 3x3 around Pixel 100,200 (99,200+100,200+101+200 etc). Match this block with a Pixelblock of 100,200 and all surrounding pixelblock (like an own pixelblock at 99,200). This way small errors at one pixel or a bit displacement won't be so bad. And small differences where a pixel is locate (rounding errors etc) won't have a large impact.

Maybe do it again only for the green channel, to simulate a grey channel image to look for structures in the image (just color problems).

pseudo code for block matching, delivers an array for each plugin with the difference of the minimum block per pixel:

Code:
const int pluginNumber = 5; //rice rice es glide n642gles arachnoid
//start big outer loop
for(int pluginCounter = 0; pluginCounter < pluginNumber; pluginCounter++)
{
    for(int currentPosY = 0; currentPosY < imageSizeY; currentPosY++)
    {
        for(int currentPosX = 0; currentPosX < imageSizeX; currentPosX++)
        {
            const int blocksize = 3;
            int minimum = 1<<30; //around 1 billion
            int tempBlockDifference = 0;
            struct imageBlock softwareImageBlock;
            struct imageBlock pluginImageBlock;

            softwareImageBlock = getImageBlock(softwareImage,currentPosY,currentPosX);

            //blocksize must a an uneven number
            for(int a = -(int)(blocksize/2); a < (int)(blocksize/2); a++)
            {
                //same here with blocksize/2
                for(int b = -(int)(blocksize/2); b < (int)(blocksize/2); b++)
                {

                    pluginImageBlock = getImageBlock(pluginImageBlock,currentPosY+a,currentPosX+;
                    tempBlockDifference = getBlockDifference(softwareImageBlock,pluginImageBlock);
                    minimum = minimum > tempBlockDifference ? tempBlockDifference : minimum;
                }
            }

            accuaryArray[pluginNumber][currentPosY][currentPosX] = minimum;    
        }
    }
}
//end big outer loop
 
Last edited by a moderator:
That seems a lot of hard work when I'm struggling to find a configuration for F-Zero that doesn't have any blatently obvious graphical problems. We don't need frame-by-frame comparison to see if a game is playable, though I agree it might be useful in the future where multiple configurations run well (and even then I'd argue you can't trust PC emulators yet, so the only way to be sure is using the real hardware).
 
We don't need frame-by-frame comparison to see if a game is playable
How would you check if a game is playable?

I said around 8 frame per game (let the game some time alone, then the demo mode can start, so you can do some screenshots). Maybe 8 frames are not enough better 30 or 60 frames, since all games have different times until the demo mode starts. But building a "quality checker" would be useful for other emulators too.

And it would be the first real world software for the Pandora where the dsp would be very useful :p .
 
To check it a game was playable, I would see if it was possible for me to play it, and see if I enjoy playing it as much as I do on the real hardware, and am not impacted or distracted by slowdown or graphical glitches. In my testing of the games I own, we're close to that but not 100% yet, and even then it only almost works with one configuration so it's easy to recommend that.


Your idea could work better IMO if it were integrated into the emulator so that it could grab screens every n real frames, so that you can compare them to the same n frames on another emulator (or real hardware if your comparison algorithm was advanced enough), with no requirements on physical timers which would be subject to the vagaries of slowdown and frameskip. But that's far from a high-priority requirement when it's still easy to compare gameplay with your eyes to a youtube video of the game if it's not obvious to the naked eye whether the game is playing correctly or not.
 
Last edited by a moderator:
Maybe Ed can make a type of glasses with strobe that when the frame drops, the strobe speeds up and vice versa to fool our brains into thinking that there's no change and hence the game runs full speed 100% of the time  :)
 
Last edited by a moderator:
Just wanted to say that I finally got a chance to dive into mupen again, and I am very impressed. When I first upgraded to a 1ghz, I didn't see much change in terms of mupen performance. Today I upgraded my sgx drivers and booted the latest mupen 2.0 pnd. There is a marked improvement in terms of speed. Some graphical issues here and there, but games like Mario kart are hard to tell they are being emulated. Full speed and no graphical issues!

I have yet to get a USB analog stick working with this. Has anyone else had luck on this front? Bluetooth and usb analogs have not worked for me on previous versions.

Sent from my Nexus S 4G using Tapatalk
 
I have yet to get a USB analog stick working with this. Has anyone else had luck on this front?
I have got both my USB to N64 controller adapter(adaptoid) and the Retrode2 with N64 adapter working fine with the latest Mupen..

Most Controllers are USB 1.0 you will need a USB 2.0 hub to make it work with the regular sized USB port..
 
Do you use qjoypad? Or does the controller just work on its own? Buttons I have never had an issue with, but analog has given me trouble in the past.

Sent from my Nexus S 4G using Tapatalk
 
It works out of the box if it detects the controller, if you check the mupen64plus config file for the input plugin you can see if it has a profile for your controller.. Hmm I've never used qjoypad..
 
Last edited by a moderator:
Ok, tried out the new Mupen for the first time and it crashed straight my pandora Completely, not so nice. So far I was only able to test StarFox shortly but it just crashed when tried training mode.


PLEASE add a proper config per game so I don''t have to try every possible plugin configuration to make a game work (this was my main concern by the way). Also, how can I lower the rtesolution, it's way to high for an CC Pandora, old mupen was able to render lower res (also an concern of me).


I really don't have time for going throufgh all configs. Is there a "save" plugin combination that does not crash the system? I have no clue about all of these plugins and settings, the old config worked fine.


Edit: glide plugin works for StarFox but still much slower than the old version. New Menu/launcher is confusing imho and I need touchscreen and controls to use it, VERY strange.
About your crash:

Do you use the latest build 07 of mupen 2 ?

Do you have the latest version of the Firmware installed?

How do you overclock? Can you post the pndrun file?

General guideline : for better speed, use GLES2N64 plugin first. If you have graphical glitches, try Glide. If you need more speed, try Rice or Glide.

The GUI doesn't need touchscreen. Use "{Select}" to configure default plugin, {Y} to configure per rom plugin, {B} to launch a game, {A} to cancel, {X} to go up a folder.

You should read the thread, most of your comment have already been debated here.
 
tried wave race with the updated gles2 plugin and overclocked to 800 it works already great, plays a lot better than before. i'll see if i can find some free time i'll tinker with the gles plugin to see what could be done resolution wise.
 
Hi


It s not possible to make fullscreen with gles2 ?


I can do it with first plugin rice or rice 1


Lolo
 
Not for now. Code is here to handle it, but there is not variable in config for that yet.

Wait for next release to enjoy stretched deformed gameplay...
 
Back
Top