Alpha Testing Underway!

[Paul]

Hmm, it seems to be registering that you touched a button.  Log from the game session:

Code: [Select]

V/SDLSurface( 4939): Resuming last session
V/SDL     ( 4939): SDL audio: opening device
V/SDL     ( 4939): SDL audio: wanted stereo 16-bit 44.1kHz, 2048 frames buffer
V/SDL     ( 4939): SDL audio: got stereo 16-bit 44.1kHz, 2400 frames buffer
W/AudioTrack( 4939): obtainBuffer() track 0x449298 disabled, restarting
W/AudioTrack( 4939): obtainBuffer() track 0x449298 disabled, restarting
V/front_end( 4939): Core Status: State loaded from: Mupen64PlusAE_LastSession.sav
W/AudioTrack( 4939): obtainBuffer() track 0x449298 disabled, restarting
W/AudioTrack( 4939): obtainBuffer() track 0x449298 disabled, restarting
V/TouchPad( 4939): Touch inside button boundaries
V/TouchPad( 4939): Pressed color 5926177
V/TouchPad( 4939): Closest match: button 9
V/SDLActivity( 4939): onUserLeaveHint()
V/SDLActivity( 4939): Saving session
This indicates that it detected a touch event inside the mask image boundaries, and recognized it as a button press for N64 button "9" (C-pad Left).  I am a little surprised there is only one event logged, though.  Could you run that same test again, and this time press all the imaginary C-buttons like 4 times each (to see if they are all registering, or if it is hanging after just one).  If everything is working up to this point in the code, it must be broken somewhere later in the linkage with the input plug-in.

[xperia64]

I updated the logcat on my previous post

[Paul]

Yep, seems to be just registering one event, and then no more.  Problem must be somewhere before this, let me put in some more log messages and I'll post another test.

I think that's the same logcat, actually (same PID, which is unlikely).  It must have not updated when you changed it.  I'll still put together that second test, though.

[Paul]

Ok, please run the same test with this one (4 presses per C button).  Make sure the game is loaded first, of course:

Xperia Play, Test3

[xperia64]

Here

[Paul]

The c buttons seem to be positioned on top of the analog control.  That narrows down the search quite a bit.  Must be a problem in the loader.

[Paul]

Haha, wow.. I'm almost too embarrass to mention what the problem was, but here:
I had this:

Code: [Select]

                            // Button color mask image in BMP image format (doesn't actually get drawn)
                            masks[buttonCount] = new Image( resources, Globals.DataDir + "/skins/touchpads/" +
                                                            skin + "/" + filename + ".bmp" );
                            // Position (percentages of the screen dimensions):
                            xpercents[buttonCount] = toInt( section.get( "x" ), 0 );
                            ypercents[buttonCount] = toInt( section.get( "y" ), 0 );
                            buttonCount++;
Instead of this 

Code: [Select]

                            // Button color mask image in BMP image format (doesn't actually get drawn)
                            masks[buttonCount] = new Image( resources, Globals.DataDir + "/skins/touchpads/" +
                                                            skin + "/" + filename + ".bmp" );
                            // Position (percentages of the screen dimensions):
                            xpercents[buttonCount] = toInt( section.get( "x" ), 0 );
                            ypercents[buttonCount] = toInt( section.get( "y" ), 0 );
                            masks[buttonCount].fitCenter( (int) ( (float) PAD_WIDTH * ((float) xpercents[buttonCount] / 100.0f) ),
                                                          (int) ( (float) PAD_HEIGHT * ((float) ypercents[buttonCount] / 100.0f) ),
                                                          PAD_WIDTH, PAD_HEIGHT );
                            buttonCount++;
So of course everything was sitting at (0,0) (the left touchpad).  I guess I better get some sleep..

ANYWAY, it will work now (assuming I didn't make any more dumb mistakes like that one):

--EDIT-- WRONG FILE!  OMG, I'm losing it!

[Paul]

Ok, this should be the right one..

Xperia Play, RC2

Now I'm going to bed.  Tomorrow I'll work on updating the forum in preparation for the expected flood of new users after I post the app on the Android Market.

[xperia64]

Sounds good. If you make a donate version I WILL buy it

[Epic_bubble]

I noticed a very small bug in the setting. Auto frameskip is enabled by default but its doesn't skip frames, when its disabled it does skip frames.

This bug could be dealt with after pushing it to the android market though since its very minor to bother compiling two new builds for it.

[Paul]

I think that's how it is supposed to behave.  When it is not "Auto", it skips the number of frames you specify.  When it is Auto, it decides internally how many frames it will skip to try and maintain the proper emulation speed (no idea how it makes this decision or even if that "auto" part works, to be honest - I just provided an interface to what was there).  Do you think this could be named something different to make it more clear?  Another thing that might confuse folks is that higher frameskip means lower FPS but higher emulation speed.  The whole concept of frameskip is very strange, but I guess it help in some cases.

[scorpio16v]

I don't think there is a bug with auto-fs.
As I understand, if you test with gles2n64, the framerate is set in gles2n64rom.conf for some games.
You should test it with another game.

Another thing:
On tablets, it loads the wrong button skin on first time. If I go to the selection menue and than back to game, it loads the right one.

Disabling the sound brings some more frames for my tegra. But why is the sound more stuttering on tegra, like on exynos ?

[Paul]

Which button skin does it load on the first run?  Also, just so I understand the behavior, all you do is go to the selection menu (without selecting something) and back to the game and then it had the correct one?  Let me write a more verbose test for you to run to see whats going on here.

As for sound being more stutery on Tegra, the only thing I can think is because it doesn't have Neon, so it isn't taking advantage of the Neon-specific optimizations.  Stuttery audio typically means slowed-down emulation.. does this happen for every game (including Mario64), or just some of them?  Does the audio quality improve if you disable the video plug-in (to rule out any issues with the audio plug-in itself)?

[scorpio16v]

If I load a game the first time, or if I change the videoplugin, it loads the Mupenplus-ae-analog skin. But under cange, it shows the correct analog-tablet skin.
I must go in the list and press the back-button ( don't need to choose the skin from the list ).
Than it loads the right skin.
If I start the game again, it didn't happen.

For sound. Yes, if I disable the video plugin the sound is smooth. Mario is no problem. But on games like Banjo-Tooie you can hear only sound fragments and the framerate drops under 10 frames.
I think you are right with your guess that the missing Neon is the problem.
In direct comparsion between my tagra phone and the tablet, is a light framedop, most likely caused by the higher resolution of the tablets screen.

[Epic_bubble]

I think that's how it is supposed to behave.  When it is not "Auto", it skips the number of frames you specify.  When it is Auto, it decides internally how many frames it will skip to try and maintain the proper emulation speed (no idea how it makes this decision or even if that "auto" part works, to be honest - I just provided an interface to what was there).  Do you think this could be named something different to make it more clear?  Another thing that might confuse folks is that higher frameskip means lower FPS but higher emulation speed.  The whole concept of frameskip is very strange, but I guess it help in some cases.

Ah I see I though that when Auto was disabled then it would disable frame skipping all together, I didn't think it would start using manual.

Anyway I set manual skipping to 0 and its fine now