PaulsCode Forum

Mupen64Plus AE => General Discussion => Topic started by: Paul on November 03, 2011, 06:31:17 PM

Title: Alpha Testing Underway!
Post by: Paul on November 03, 2011, 06:31:17 PM
- Updated 18 December 2011 -

Alpha Testing Phase Has Ended

Visit this thread (http://www.paulscode.com/forum/index.php?topic=96.msg2243#msg2243) to get involved in Beta Testing (includes links to latest versions and source code)


Bug-fixes completed:

- pointed front-end to correct configuration path so defaults are not always used
- fixed crash on devices without SDCard at /mnt/sdcard
- shut down app smoothly when user presses "Home" to leave
- mapped common Android buttons to recognizable SDL scancodes
- SDL scancodes print to logcat output when buttons are pressed (for manual input config)
- mapped all known Android keycodes to unique SDL scancodes
- added Toast message displaying SDL scancodes for keys when pressed
- stopped device from entering sleep mode while app is running
- fixed 50-second crash bug
- fixed toast message code crash after 257 button presses
- added on-screen virtual gamepad
- added gamepad layouts for small screens and tablets
- fixed problem where touchscreen stopped responding after 50 seconds
- fixed problem where virtual gamepad was preventing keys mapped to analog axis from functioning
- fixed performance drain caused by redrawing the analog stick
- fixed "easy-to-drop" analog stick, improved responsiveness

- enabled volume up/down keys to control the volume
- fixed random crashes
- created separate SDL Scancode Finder app, removed scancode notifications from emulator app
- fixed crash when slide-out keypads or gamepads are opened or closed while app is running
- fixed crash caused by incoming calls or other view changes
- implemented Eeprom clock emulation
- fixed virtual gamepad responsiveness on some devices
- fixed missing key detection for core functions
- added game session save/ resume capability
- added save-game slot choosing capability
- implemented a basic GUI
- added support for zipped ROMs
- fixed menu crash when leaving game and returning to menu
- fixed plug-in "enable" checkboxes
- added option to disable volume keys when using them as controller buttons
- improved virtual gamepad redraw speed
- fixed "disappearing button" bug in virtual gamepad
- fixed analog-image unresponsive bug in virtual gamepad
- added customizable FPS indicator
- added option to emulate analog control as an octagon (more accurate)
- implemented "stick capture" logic making full-throttle moves easier
- fixed reverse mapping bug for analog up/down
- fixed gamepad forgetting what settings you picked
GLES2N64 Bug-fixes:
- fixed polygon sort-order problem (introduced depth-buffer bug on Qualcomm chipsets!)
- fixed side-bar graphics glitches
- fixed depth-buffer bug on Qualcomm chip-sets
- fixed shader bug on devices without Neon
- added hardware profiling to fix missing shadows and door stars in Mario64
- added screen-stretch option
- added frame-skip interface
GLES2Rice Bug-fixes:
- Frame sized incorrectly
- Most polygons missing or textured black
- Fixed emulator not stopping after choosing "Close" from in-game menu
- Fixed incorrect normals problem

Remaining known problems: (at the end of the Alpha Testing phase)

- virtual gamepad analog stick disappears randomly (reappears quickly, or stays gone until next touch event)
- Emulation runs too fast on some devices
- RGB565 format causes poor dithering effect on some devices (should use RGB888)
- Core reset function freezes the app
- APK compiled from source code hangs on black screen (see notes below for workaround)
GLES2N64 Problems:
- Mario's hat and face have incorrectly-shaded polygons on devices without Neon when VEC4 optimization enabled
- Mario's right-eye colored red on devices without Neon when VEC4 optimization disabled
GLES2Rice Problems:
- Slow frame-rate
- 2D texture problems
- Flickering shadows, carpets, etc. in Mario64
- Incorrect sorting of some objects
- Incorrect texture coordinates
- Hi-res texture support not implemented
- Screen-stretch not implemented
- Frame-skip not implemented


This product is not affiliated with, nor authorized, endorsed or licensed in any way by Nintendo Corporation, its affiliates or subsidiaries. All trademarks are property of their respective holders. All individual games screen shots or audio that are simulated by Mupen64Plus AE are property of their respective copyright holders and are only used for the purpose of informing the customer of the software's functionality.  You must have the right to a given ROM before you play it.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 03, 2011, 06:33:02 PM
Project Overview

This project is the development of a Nintendo 64 Emulator for Android.  The concept began back in December 2010, after I was playing around with various N64 emulators for PC, including Project64 and Mupen64Plus.  I was so impressed with the progress that had been made on Mupen64Plus since I'd used it last, that I decided to dig around in the source code.  I really fell in love with the API and the modular nature of the code.  I decided to see if I could contribute to the emulation effort by attempting to port the code to an Android app.

The goal of this project is to develop a fully open-source Nintendo 64 emulator for Android, that is true to the official Mupen64Plus 2.0 API and compatible on a wide variety of devices and architectures.  My hope is that this will spark future development efforts to provide optimizations, alternate plug-ins, and ROM compatibility improvements.  Ultimately, the goal is that these efforts might eventually contribute back to the original project.


The history of this thread used to be much longer.  However, due to a database bug, I was forced to remove the forum archives.  They are backed up, and will be restored at some point in the future when I purchase a new hosting service.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 03, 2011, 06:36:48 PM
Quote from: scorpio16v
Quote
Some folks have reported that this same bug also affects Zelda 64 in a couple of areas (it appears to be considerably more prevalent in Shadow Man, though). Just out of curiosity, does this bug also affect N64oid with the gles2n64 plug-in?

On N64oid 1.1.4 it's the same bug
On 2.2.3 and 2.4.1 are no lights and the menue is missing on gles2n64 plugin.
Yongzh's "default" plugin has no bugs in Shadow Man.

For info: I bought the market and the slide me versions. So I didn't test warez.

Another bug that affects only gles2n64:

The buggy shadow in Pilotwings is in gles2n64 plugin, background is ok.
On default plugin the shadow is ok, but background has a bug and on this plugin, the game has a colored frame instead a black one.

Btw. the shadow in Pilotwings is in older Pandora ports and is fixed in newer.

pilotwings gles2n64
http://db.tt/KBXdpZmi

n64oid 'default' plugin (colored frame is only in menue screens)
http://db.tt/mDuSVgts
http://db.tt/H8CLEEsd

And now pilotwings on mupen64plus-ae

missing background
http://db.tt/wpJGirjr

and flickering background (only mali400 specific)
http://db.tt/fzMVtlHg



Quote from: scorpio16v
Quote from: Paul
Quote from: scorpio16v
Is it possible to start mupen64plus-ae from comandline under Android with further arguments ?
[No it is not possible (this is the reason I hard-coded the ROM name "mario.n64" when starting the app). 

And the command ' am start' can't be used for that ?

http://learnandroid.blogspot.com/2008/01/run-android-application-from-command.html

Quote from: Kris
Hi Paul I've uploaded the source to my port of rice to gles 2 here (https://www.box.net/shared/37o2ii3c049mrb87aajo). There are still problems with 2d elements and alpha test at the moment as there is another issue I've been trying to solve for about a week. The result is an incorrectly shaded mario (https://www.box.net/shared/kjykeo2dztrrta4qibgl) and it seems similar to the problems with the various optimisations with the gles2n64 plugin.

Something is happening to the texture coordinates: the specular highlight of mario is from a texture so it gets mapped incorrectly this also causes problems in Yoshis story. Pictures of bad (https://www.box.net/shared/vrdgo41lmeg8q57voktk) and good (https://www.box.net/shared/rhicxmr8a7478exhc897) texture coordinates.

It's pretty frustrating as the same code I posted runs on desktop gl fine, it may also work on different arm devices I've only been working with the touchpad. I've tried all the fpu and math compiler settings and using software didn't help, I guess the next step is to use the math functions from gles2n64. I've found performance to be about the same as the other plugin even though rice hasn't got any arm specific code. Conker's intro looked good although it was quite slow.

You will probably need to look at the init code in COGLGraphicsContext::Initialize and maybe the texture format in COGLTexture::EndUpdate. GLES_2 needs to be defined somewhere but the eclipse project files already do this. I've got a version which uses egl to init based on gles2n64 that you could have. Let me know how it goes or if you've got any questions.

W.r.t the cheat functionality in mupen, this seemed to work ok, I used it to enable the fix for zelda's laggy menu screens.

P.s has anyone tried Majora's Mask on Mupen64Plus AE?, my port hangs early in the forest.

Quote from: Kris
Quote from: koekje
What cheat is that, and do you think I can use it on n64oid?

I got the zelda cheat from here (http://www.emutalk.net/threads/13878-Ocarina-of-Time-subscreen-delay-fix-codes-for-all-ROMs), I think it would work in n64oid. I don't know where n64oid stores its files but you will need to edit mupencheat.txt along the lines of
Quote
crc 693BA2AE-B7F14E9F-C:45
gn Legend of Zelda, The - Ocarina of Time (U) (V1.2)
 cn Subscreen\delay fix
  801DAE8B 0002
You can search for the first 2 lines and I think it will remain if you use the emulators save states.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 03, 2011, 09:55:32 PM
Quote from: Kris
Hi Paul I've uploaded the source to my port of rice to gles 2 here (https://www.box.net/shared/37o2ii3c049mrb87aajo).

I'll port this to Android and start doing a little digging to see if I can help find the cause of the bugs.  Could you post the makefile you are using for this (or the list of which .cpp files should be compiled and any build flags)?
Title: Re: Alpha Testing Underway!
Post by: ringo20000 on November 03, 2011, 10:20:10 PM
On the Xperia play, does the d-pad not work when the touchpad is enabled?  I have all the keys mapped and everything else seems to work except the d-pad.  Is it either the touchpad or d-pad?
Title: Re: Alpha Testing Underway!
Post by: Kris on November 03, 2011, 11:39:31 PM
I'll port this to Android and start doing a little digging to see if I can help find the cause of the bugs.  Could you post the makefile you are using for this (or the list of which .cpp files should be compiled and any build flags)?

I've been working with eclipse and the C/C++ plugin and 'C/C++ GCC Cross Compiler Support' plugins and the project files are in the zip, not that I'm recommending them.

The original makefile (https://bitbucket.org/richard42/mupen64plus-video-rice/src/4d1f7a6b4a15/projects/unix/Makefile) could be a good start if you change:
Remove references to the deleted files: CNvTNTCombiner.cpp, OGLCombinerNV.cpp, OGLCombinerTNT2.cpp.
Remove references to the files in /liblinux: BMGImage.c, BMGUtils.cpp, bmp.c, pngrw.c
Pass NO_ASM into make.
You also need the preprocessor definition GLES_2 or you could edit OGLPlatform.h
Link to the GLESv2 and SDL libraries and headers.

It might be easier to edit the makefile for gles2n64, basically define NO_ASM, GLES_2 and compile all the files except the ones in /liblinux and the win32 one. For a release build the same sort of flags like -O3 or -Ofast and -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -funsafe-math-optimizations -ffast-math -fsingle-precision-constant

It's probably also worth noting that whereas gles2n64 does everything itself rice uses vidext from the core for some init, swapbuffers and other routines. I'm not convinced the vidext functions are necessary in the core but that's another thing.

I think the init code in COGLGraphicsContext::Initialize will probably require the most changes and I can post a different version that uses egl, the code in the zip works on windows and the touchpad. I used the egl from gles2n64 to get it to work on windows with the qualcomm gles emulator libs.

Good luck.
Title: Re: Alpha Testing Underway!
Post by: Ganster41 on November 04, 2011, 04:34:15 AM
Hi all! May be on devices without NEON you use VFP? With soft float it runs slow on 748MHz ARMv6, and older devices without VFP anyway can't play comfortly) May be I try to compile your project myself with needed flags later...
Mario64 runs ok, but sound so laggy. Why?
Did you try to run Star Wars Episode I: Racer? Some textures are invisible there(ex. car body, characters models in selection menu...).
PS. Sorry for my bad English.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 04, 2011, 06:34:49 AM
On the Xperia play, does the d-pad not work when the touchpad is enabled?  I have all the keys mapped and everything else seems to work except the d-pad.  Is it either the touchpad or d-pad?

I doubt that is the case, but I can check, if you post your logcat output after touching the buttons for the d-pad and touching the touchpad.

Hi all! May be on devices without NEON you use VFP? With soft float it runs slow on 748MHz ARMv6, and older devices without VFP anyway can't play comfortly) May be I try to compile your project myself with needed flags later...
I can look into this (I'll have to look up the correct flags and when they can be used, unless you happen to know off hand)

Mario64 runs ok, but sound so laggy. Why?
This is because the framerate is too low, due to your slow ARM6 device.  Overclocking might help improve this, otherwise you will have to disable the audio.

I think the init code in COGLGraphicsContext::Initialize will probably require the most changes and I can post a different version that uses egl, the code in the zip works on windows and the touchpad. I used the egl from gles2n64 to get it to work on windows with the qualcomm gles emulator libs.
Hey, if you could post that egl version for comparison, it would be great (I'll work on this tonight after I get home from work).
Title: Re: Alpha Testing Underway!
Post by: Ganster41 on November 04, 2011, 06:43:10 AM
You can use -mfloat-abi=softfp -mfpu=vfp for ARMv6 VFP. I think GCC from NDK should support it too...
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 04, 2011, 06:53:35 AM
On the Xperia play, does the d-pad not work when the touchpad is enabled?  I have all the keys mapped and everything else seems to work except the d-pad.  Is it either the touchpad or d-pad?

Have you mapped the xperia dpad buttons the the n64 dpad or analog stick? The n64 dpad doesn't do anything in mario64. What I did was map the xperia buttons to the n64 analog stick so I can use both the touchpad and dpad for controlling mario.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 04, 2011, 07:48:34 AM
Wow, this theme is hard to read on my phone.  I'll definitely have to change the normal text color to a lighter grey than it is now.
Title: Re: Alpha Testing Underway!
Post by: koekje on November 04, 2011, 08:01:02 AM
crc 693BA2AE-B7F14E9F-C:45
gn Legend of Zelda, The - Ocarina of Time (U) (V1.2)
 cn Subscreen\delay fix
  801DAE8B 0002

Does this also work with V1.0?


NVM looked at the site you gave and there it was for 1.0 :) thank you!
Title: Re: Alpha Testing Underway!
Post by: crualfoxhound on November 04, 2011, 09:24:55 AM
@Paul.

I be getting my galaxy note delivered shortly.
hopefully early next week.
So I can use both HTC Desire HD and Samsung galaxy note.
To help testing.

Catch ya later.

PS really like the new coloured  forum.
Title: Re: Alpha Testing Underway!
Post by: Kris on November 04, 2011, 09:33:32 AM
Here's the version with the egl init code from gles2n64. (https://www.box.net/shared/qu5s6qjco2vpqqd16c2d)
Title: Re: Alpha Testing Underway!
Post by: ringo20000 on November 04, 2011, 11:42:37 AM
On the Xperia play, does the d-pad not work when the touchpad is enabled?  I have all the keys mapped and everything else seems to work except the d-pad.  Is it either the touchpad or d-pad?

Have you mapped the xperia dpad buttons the the n64 dpad or analog stick? The n64 dpad doesn't do anything in mario64. What I did was map the xperia buttons to the n64 analog stick so I can use both the touchpad and dpad for controlling mario.

That was it.  I had the d-pad mapped to the d-pad instead of x,y axis.  I knew it was something simple I was missing.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 04, 2011, 09:24:19 PM
Here's the version with the egl init code from gles2n64. (https://www.box.net/shared/qu5s6qjco2vpqqd16c2d)

Do you have any name preferences for your plug-in? (I was just going to go with something generic like "GLES2Rice", but I want to be sure and use whatever name you came up with, so you get credit for your hard work).
Title: Re: Alpha Testing Underway!
Post by: Paul on November 04, 2011, 10:32:03 PM
May be on devices without NEON you use VFP? With soft float it runs slow on 748MHz ARMv6, and older devices without VFP anyway can't play comfortly

Here is a build with VFP c-flags:

ARM6, VFP Test (http://www.paulscode.com/source/Mupen64Plus-AE/04NOV2011/Mupen64Plus-debug-vfp.apk)

This will break the emulator on ARM5 devices (there doesn't seem to be a provision for specifying an ARM6-only build in the Android makefiles - it lumps ARM6 and ARM5 together under the heading "armeabi").

Everyone with an ARM6 device, please run this test and let me know if it has any effect on performance (better, worse, or no noticeable change)
Title: Re: Alpha Testing Underway!
Post by: goodboy735 on November 05, 2011, 01:07:41 AM
It's about the same for me... Don't see any graphical gliches..

PS: Would there be a way to get an onscreen fps display? or even average fps every few seconds in the logcat..
Title: Re: Alpha Testing Underway!
Post by: Ganster41 on November 05, 2011, 03:39:52 AM
Work fine on my Orange San Francisco(MSM7227 ARM1136EJ-S). Don't know faster or not, but works. Mario64 works without visible lags and without VFP, I try other ROM later...
Sound still laggy(
Title: Re: Alpha Testing Underway!
Post by: MaXiMu on November 05, 2011, 07:25:46 AM

I test armv6 vfp possible small speed up but unstable crash if push x button

Code: [Select]
I/ActivityManager( 2020): Start proc paulscode.android.mupen64plus for activity paulscode.android.mupen64plus/.SDLActivity: pid=5157 uid=10044 gids={3003, 1015}

D/dalvikvm( 5157): Trying to load lib /data/data/paulscode.android.mupen64plus/lib/libSDL.so 0x45c79528

D/dalvikvm( 5157): Added shared lib /data/data/paulscode.android.mupen64plus/lib/libSDL.so 0x45c79528

D/dalvikvm( 5157): Trying to load lib /data/data/paulscode.android.mupen64plus/lib/libcore.so 0x45c79528

D/dalvikvm( 5157): Added shared lib /data/data/paulscode.android.mupen64plus/lib/libcore.so 0x45c79528

D/dalvikvm( 5157): No JNI_OnLoad found in /data/data/paulscode.android.mupen64plus/lib/libcore.so 0x45c79528, skipping init

D/dalvikvm( 5157): Trying to load lib /data/data/paulscode.android.mupen64plus/lib/librsp-hle.so 0x45c79528

D/dalvikvm( 5157): Added shared lib /data/data/paulscode.android.mupen64plus/lib/librsp-hle.so 0x45c79528

D/dalvikvm( 5157): No JNI_OnLoad found in /data/data/paulscode.android.mupen64plus/lib/librsp-hle.so 0x45c79528, skipping init

D/dalvikvm( 5157): Trying to load lib /data/data/paulscode.android.mupen64plus/lib/libinput-sdl.so 0x45c79528

D/dalvikvm( 5157): Added shared lib /data/data/paulscode.android.mupen64plus/lib/libinput-sdl.so 0x45c79528

D/dalvikvm( 5157): No JNI_OnLoad found in /data/data/paulscode.android.mupen64plus/lib/libinput-sdl.so 0x45c79528, skipping init

D/dalvikvm( 5157): Trying to load lib /data/data/paulscode.android.mupen64plus/lib/libaudio-sdl.so 0x45c79528

D/dalvikvm( 5157): Added shared lib /data/data/paulscode.android.mupen64plus/lib/libaudio-sdl.so 0x45c79528

D/dalvikvm( 5157): No JNI_OnLoad found in /data/data/paulscode.android.mupen64plus/lib/libaudio-sdl.so 0x45c79528, skipping init

D/dalvikvm( 5157): Trying to load lib /data/data/paulscode.android.mupen64plus/lib/libgles2n64.so 0x45c79528

D/dalvikvm( 5157): Added shared lib /data/data/paulscode.android.mupen64plus/lib/libgles2n64.so 0x45c79528

D/dalvikvm( 5157): No JNI_OnLoad found in /data/data/paulscode.android.mupen64plus/lib/libgles2n64.so 0x45c79528, skipping init

D/dalvikvm( 5157): Trying to load lib /data/data/paulscode.android.mupen64plus/lib/libmain.so 0x45c79528

D/dalvikvm( 5157): Added shared lib /data/data/paulscode.android.mupen64plus/lib/libmain.so 0x45c79528

V/SDLActivity.java( 5157): CPU info available from file /proc/cpuinfo:

V/SDLActivity.java( 5157): Processor : ARMv6-compatible processor rev 5 (v6l)

V/SDLActivity.java( 5157): BogoMIPS : 791.34

V/SDLActivity.java( 5157): Features : swp half thumb fastmult vfp edsp java

V/SDLActivity.java( 5157): CPU implementer : 0x41

V/SDLActivity.java( 5157): CPU architecture: 6TEJ

V/SDLActivity.java( 5157): CPU variant : 0x1

V/SDLActivity.java( 5157): CPU part : 0xb36

V/SDLActivity.java( 5157): CPU revision : 5

V/SDLActivity.java( 5157):

V/SDLActivity.java( 5157): Hardware : IMAPX200

V/SDLActivity.java( 5157): Revision : 0000

V/SDLActivity.java( 5157): Serial : 0000000000000000

V/SDLActivity.java( 5157): ����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

I/System.out( 5157): libSDL: Creating startup screen

I/System.out( 5157): libSDL: Starting data downloader

I/System.out( 5157): libSDL: Starting downloader

I/global  ( 5157): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required.

I/global  ( 5157): Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required.

V/GamePad ( 5157): Mupen64Plus AE Analog Touch

V/GamePad ( 5157):     ver 1.0

V/GamePad ( 5157):     Analog gamepad with a clean, intuitive layout

V/GamePad ( 5157):     Author: roymustang16 and Paul Lamb

D/dalvikvm( 5157): GC_EXTERNAL_ALLOC freed 1543 objects / 144664 bytes in 58ms

D/dalvikvm( 5157): GC_EXTERNAL_ALLOC freed 424 objects / 355088 bytes in 46ms

V/SDL     ( 5157): pixel format OPAQUE (using SDL_PIXELFORMAT_RGB565)

I/SDL     ( 5157): SDL_Android_Init()

V/front_end( 5157):  __  __                         __   _  _   ____  _             

V/front_end( 5157): |  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___

V/front_end( 5157): | |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __| 

V/front_end( 5157): | |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \ 

V/front_end( 5157): |_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/ 

V/front_end( 5157):              |_|         http://code.google.com/p/mupen64plus/ 

V/front_end( 5157): Mupen64Plus Console User-Interface Version 1.99.4

V/front_end( 5157):

V/core_interface( 5157): UI-console: attached to core library 'Mupen64Plus Core' version 1.99.4

V/core_interface( 5157):             Includes support for Dynamic Recompiler.

I/ActivityManager( 2020): Displayed activity paulscode.android.mupen64plus/.SDLActivity: 795 ms (total 795 ms)

V/front_end( 5157): Core: Goodname: Super Mario 64 (U) [!]

V/front_end( 5157): Core: Name: SUPER MARIO 64

V/front_end( 5157): Core: MD5: 20B854B239203BAF6C961B850A4A51A2

V/front_end( 5157): Core: CRC: ff2b5a63 2623028b

V/front_end( 5157): Core: Imagetype: .v64 (byteswapped)

V/front_end( 5157): Core: Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)

V/front_end( 5157): Core: Version: 44140000

V/front_end( 5157): Core: Manufacturer: 4e000000

V/front_end( 5157): Core: Country: USA

V/cheat   ( 5157): UI-Console: Cheat codes disabled.

V/front-end( 5157): UI-console: using Video plugin: 'gles2n64' v0.0.5

V/front-end( 5157): UI-console: using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v1.99.4

V/front_end( 5157): Input: No auto-configuration found for device 'Android accelerometer'

V/front_end( 5157): Input: N64 Controller #1: Forcing default keyboard configuration

V/front_end( 5157): Input: Using auto-configuration for device 'Keyboard'

V/front-end( 5157): UI-console: using Input plugin: 'Mupen64Plus SDL Input Plugin' v1.99.4

V/front-end( 5157): UI-console: using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v1.99.4

D/gles2n64( 5157): [gles2n64]: Loading Config from data/gles2n64.conf

D/gles2n64( 5157): Rom is NTSC

D/gles2n64( 5157): [gles2N64]: Searching data/gles2n64rom.conf Database for "SUPER MARIO 64" ROM

D/gles2n64( 5157): Initializing SDL video subsystem...

D/gles2n64( 5157): Setting video mode 800x480...

I/SDL     ( 5157): [STUB] GL_LoadLibrary

V/SDL     ( 5157): Starting up OpenGL ES 2.0

D/libEGL  ( 5157): loaded /system/lib/egl/libEGL_VIVANTE.so

D/libEGL  ( 5157): loaded /system/lib/egl/libGLESv1_CM_VIVANTE.so

D/libEGL  ( 5157): loaded /system/lib/egl/libGLESv2_VIVANTE.so

I/SDL     ( 5157): [STUB] GL_SetSwapInterval

I/SDL     ( 5157): [STUB] GL_GetSwapInterval

E/gralloc ( 5157): handle 0x2a7d00 not locked

V/gles2N64 (OpenGL)( 5157): Using settings for hardware profile IMAP (-0.001f, -0.001f)

E/gralloc ( 5157): handle 0x2a8c20 not locked

V/front_end( 5157): Input: N64 Controller #1: Using keyboard/mouse

V/front_end( 5157): Input: 1 controller(s) found, 1 plugged in and usable in the emulator

V/front_end( 5157): Input: Mupen64Plus SDL Input Plugin version 1.99.4 initialized.

I/ActivityManager( 2020): Process com.noshufou.android.su (pid 5112) has died.

V/front_end( 5157): Audio: Initializing SDL audio subsystem...

V/SDL     ( 5157): SDL audio: opening device

V/SDL     ( 5157): SDL audio: wanted stereo 16-bit 44.1kHz, 2048 frames buffer

V/SDL     ( 5157): SDL audio: got stereo 16-bit 44.1kHz, 4096 frames buffer

D/ALSAModule( 1956): open called for devices 00000002 in mode 0...

D/        ( 1956): [external/alsa-lib/src/pcm/pcm_hw.c]:snd_pcm_hw_prepare

I/ALSAModule( 1956): Initialized ALSA PLAYBACK device default

I/ActivityManager( 2020): Process com.android.quicksearchbox (pid 5086) has died.

I/ActivityManager( 2020): Process siir.es.adbWireless (pid 5104) has died.

I/WindowManager( 2020): WIN DEATH: Window{45e7fe60 siir.es.adbWireless/siir.es.adbWireless.adbWireless paused=false}

I/ActivityManager( 2020): Process com.android.settings (pid 5144) has died.

V/front_end( 5157): Core: Starting R4300 emulator: Dynamic Recompiler

I/ActivityManager( 2020): Process android.process.acore (pid 3201) has died.

I/WindowManager( 2020): WIN DEATH: Window{45e53a88 mobi.SyndicateApps.ICSPlus/mobi.SyndicateApps.ICSv2.Launcher paused=false}

I/ActivityManager( 2020): Low Memory: No more background processes.

V/SDL     ( 5157): SDL audio: opening device

V/SDL     ( 5157): SDL audio: wanted stereo 16-bit 44.1kHz, 2048 frames buffer

V/SDL     ( 5157): SDL audio: got stereo 16-bit 44.1kHz, 4096 frames buffer

D/ALSAModule( 1956): open called for devices 00000002 in mode 0...

D/        ( 1956): [external/alsa-lib/src/pcm/pcm_hw.c]:snd_pcm_hw_prepare

I/ALSAModule( 1956): Initialized ALSA PLAYBACK device default

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

D/skia    ( 2020): purging 121K from font cache [14 entries]

D/dalvikvm( 2020): GC_EXPLICIT freed 17404 objects / 805280 bytes in 118ms

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

V/front_end( 5157): Audio Warning: AiLenChanged(): Audio buffer overflow.

W/AudioTrack( 5157): obtainBuffer timed out (is the CPU pegged?) 0x2ae470 user=00001000, server=00000000

D/ALSAModule( 1956): open called for devices 00000002 in mode 0...

D/        ( 1956): [external/alsa-lib/src/pcm/pcm_hw.c]:snd_pcm_hw_prepare

I/ALSAModule( 1956): Initialized ALSA PLAYBACK device default

D/gles2n64( 5157): UCODE CRC=0x6932365f

E/gralloc ( 5157): handle 0x2a7d00 not locked

D/dalvikvm( 2111): GC_EXPLICIT freed 14 objects / 416 bytes in 128ms

V/tlb     ( 5157): Enabled TLB

W/AudioTrack( 5157): obtainBuffer timed out (is the CPU pegged?) 0x2ae470 user=0004e000, server=0004d000

D/ALSAModule( 1956): open called for devices 00000002 in mode 0...

D/        ( 1956): [external/alsa-lib/src/pcm/pcm_hw.c]:snd_pcm_hw_prepare

I/ALSAModule( 1956): Initialized ALSA PLAYBACK device default

D/dalvikvm( 2107): GC_EXPLICIT freed 717 objects / 30528 bytes in 104ms

D/dalvikvm( 2702): GC_EXPLICIT freed 6 objects / 208 bytes in 91ms

W/AudioTrack( 5157): obtainBuffer timed out (is the CPU pegged?) 0x2ae470 user=00078000, server=00077000

D/ALSAModule( 1956): open called for devices 00000002 in mode 0...

D/        ( 1956): [external/alsa-lib/src/pcm/pcm_hw.c]:snd_pcm_hw_prepare

I/ALSAModule( 1956): Initialized ALSA PLAYBACK device default

W/KeyCharacterMap( 5157): No keyboard for id 0

W/KeyCharacterMap( 5157): Using default keymap: /system/usr/keychars/qwerty.kcm.bin

I/        ( 5157): [KEYOPS JNI] JNIforKeyops loading.

V/SDL_androidkeyboard( 5157): Converted Android KeyCode 52 into SDL ScanCode 27

V/front_end( 5157): Core: R4300 emulator finished.

V/core    ( 5157):     R4300 CPU core finished, shutting down

V/SDL_androidkeyboard( 5157): Converted Android KeyCode 52 into SDL ScanCode 27

V/SDL_androidkeyboard( 5157): Converted Android KeyCode 52 into SDL ScanCode 27

V/core    ( 5157):     Calling SDL_Quit()

I/SDL     ( 5157): [STUB] GL_UnloadLibrary

D/gles2n64( 5157): Stopping OpenGL

V/front_end( 5157): Core Status: Rom closed.

I/WindowManager( 2020): WIN DEATH: Window{45e57048 SurfaceView paused=false}

I/ActivityManager( 2020): Process paulscode.android.mupen64plus (pid 5157) has died.

I/WindowManager( 2020): WIN DEATH: Window{45ee5418 paulscode.android.mupen64plus/paulscode.android.mupen64plus.SDLActivity paused=false}
Title: Re: Alpha Testing Underway!
Post by: Paul on November 05, 2011, 07:35:45 AM
I test armv6 vfp possible small speed up but unstable crash if push x button

From the logcat, it looks like a normal shutdown without any errors as soon as you press the button with scancode 27.  Is scancode 27 the X button?  If so, that is normal, because in [sdcard]/app-data/paulscode.android.mupen64plus/mupen64plus.cfg the scancode for "Stop" is 27 by default (you can change this to something else, if you need the X button).
Title: Re: Alpha Testing Underway!
Post by: Paul on November 05, 2011, 07:45:03 AM
Would there be a way to get an onscreen fps display? or even average fps every few seconds in the logcat..
I'm planning to add an optional fps object type to the virtual gamepad skins, which would allow you to define where on the screen the FPS counter would be positioned (top-left by default) when an option is checked in the GUI.  I'll have to fix the redraw bug first, though.  It's on my to-do list  ;D
Title: Re: Alpha Testing Underway!
Post by: MaXiMu on November 05, 2011, 08:02:36 AM

ah I view now it you added the function to exit the emulator Good function  ;D

Title: Re: Alpha Testing Underway!
Post by: Ganster41 on November 05, 2011, 08:29:53 AM
Oh, why Google doesn't implement OpenSL ES library in Android lesser then 2.3 :( With it possible to use hardware accelerated audio playback...
Title: Re: Alpha Testing Underway!
Post by: Paul on November 05, 2011, 08:50:08 AM
I've added FPS logging to the logcat output for those of you who have been asking for it.  I'm not sure if I'm doing the calculation correctly, though.  I have it checking the system time every 30 calls to flip the EGL buffers.  In theory, the EGL buffers should be getting flipped once per frame.  I'm getting between 27-30 FPS on Mario64, but the target FPS in gles2n64rom.conf is at 25 FPS (that's why I'm not sure if I'm doing the calculation correctly).  It should still be close enough to be useful, though.

FPS Test (http://www.paulscode.com/source/Mupen64Plus-AE/05NOV2011/Mupen64Plus-debug-FPS.apk)
Title: Re: Alpha Testing Underway!
Post by: Ganster41 on November 05, 2011, 09:30:26 AM
In Mario64 I get 12-16 FPS, in Zelda: Ocarina of Time - 7-9 :(
Title: Re: Alpha Testing Underway!
Post by: Paul on November 05, 2011, 10:52:51 AM
Porting GLES2Rice is taking a bit more time than I expected.  Hit a bit of a snag because STL is handled a little weird in Android (so the compiler get's stuck on GeneralCombiner.h when it tries to include <vector>).  This is fairly well documented, though, so I should have the solution figured out if I do a little more googling.
Title: Re: Alpha Testing Underway!
Post by: koekje on November 05, 2011, 11:17:38 AM
If this rice port works will we be able to use texture packs?
Title: Re: Alpha Testing Underway!
Post by: Paul on November 05, 2011, 01:18:38 PM
If this rice port works will we be able to use texture packs?

That's definitely the goal, but it will take some more work to get it to a usable level of performance.  I've got it more-or-less running on Android, but it has two new bugs that I'll have to work out (most likely related to the initialization code I added).  Here is the .apk and source-code:

Test APK (http://www.paulscode.com/source/Mupen64Plus-AE/05NOV2011/Mupen64Plus-debug.apk)  (source code (http://www.paulscode.com/source/Mupen64Plus-AE/05NOV2011/mupen64plus-SDL1.3-source.zip))

To switch to GLES2Rice, edit mupen64plus.cfg and scroll to the bottom.  Change the filename from libgles2n64.so to libgles2rice.so.  The first new bug in the code I added is that a lot of polygons are either missing or textured black (in game I can see most of the Mario model, but everything else is not visible).  The second new bug is that the frame is too large for the screen.  The framerate averages the same for both video plug-ins on my phone, which is a good sign (could mean it will perform better than gles2n64 once some ARM7a/Neon optimizations have been developed).

It might be good to try it out on some different devices (Qualcomm in particular, since that is what Kris has tested it on) to see if there are any differences and maybe give me some ideas.  I'm not going to focus too much more on debugging this plug-in until I finish the GUI, though (I get side-tracked too easily.. I need to make myself stay on track, haha!)
Title: Re: Alpha Testing Underway!
Post by: Kris on November 05, 2011, 01:40:07 PM
The code for hires textures is currently commented out as it means there are fewer libraries needed to compile but it should be easy enough to fix or use SDL_Image instead.

I hardcoded 1024x768 in one or two places. If you check EndUpdate in OGLTexture it is probably the texture format that needs to be changed. You can test it with GL_RGBA, the colours will be wrong but you can see if that is the issue. The spec says they should be the same but BGRA is convenient and works for a few devices. You could swap the R,B bytes yourself before gltexture2D I'd copy the data and swap that instead of swaping the original just in case.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 05, 2011, 01:43:09 PM
the newest test wont work on xperia x8 but, keep going Paul  is the GUI finish ? could you make some  tests of the GUI ? :D
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 05, 2011, 01:54:20 PM
After first tests with pilotwings, i found out the following :

-on tegra2 and exynos, no shadow bug and background became visible  (as far,as I can recognize   :D )
-on exynos, no background flickering polygons
- I can see the same bright frame in menue screen, like on yongzh's default plugin. Maybe he did port the rice plugin ?
(http://db.tt/9nXHr9Jv)
Title: Re: Alpha Testing Underway!
Post by: Mats on November 05, 2011, 02:05:09 PM
maybe, you could ask him :-D
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 05, 2011, 02:14:58 PM
k so on my xperia play, every texture appears to be missing and just some colored square/rectangle. In SM64, mario is the only thing visible (sometimes i see the shadows of where stuff is supposed to be) and his face is missing its textures. in kirby64, No part of the menu shows up (textures again) and kirby's face is missing. All of the enemies' attacks look like something blocky square out of super paper mario.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 05, 2011, 02:34:37 PM
Maybe he did port the rice plugin ?
maybe, you could ask him :-D

Haha, I doubt he would admit using any code from Rice or gles2n64 (or he'd have to release the source, since both are under the GPL).
Title: Re: Alpha Testing Underway!
Post by: Mats on November 05, 2011, 02:37:40 PM
hahahaha :-D im so stupid :-P
Title: Re: Alpha Testing Underway!
Post by: Mats on November 05, 2011, 02:47:02 PM
what is the name on the a and b buttons so i can map them :-D
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 05, 2011, 02:57:02 PM
what is the name on the a and b buttons so i can map them :-D

You should use the scancode finder and the explanation from the first post.  ;)
Title: Re: Alpha Testing Underway!
Post by: Mats on November 05, 2011, 02:59:34 PM
okei thanx ;D
Title: Re: Alpha Testing Underway!
Post by: Paul on November 05, 2011, 03:44:53 PM
The code for hires textures is currently commented out as it means there are fewer libraries needed to compile but it should be easy enough to fix or use SDL_Image instead.

I hardcoded 1024x768 in one or two places. If you check EndUpdate in OGLTexture it is probably the texture format that needs to be changed. You can test it with GL_RGBA, the colours will be wrong but you can see if that is the issue. The spec says they should be the same but BGRA is convenient and works for a few devices. You could swap the R,B bytes yourself before gltexture2D I'd copy the data and swap that instead of swaping the original just in case.
Nice!  You've correctly identified both my problems.  I fixed the framesize problem by setting the config ints for "ScreenWidth" and "ScreenHeight", which are assigned to windowSetting.uDisplayWidth and windowSetting.uDisplayHeight, and used those two in the spots where 1024x768 was hard-coded.  For the missing/black textures, GL_BGRA_IMG is missing on Android, and switching to just GL_BGRA results in the aforementioned problem.  Changing it to GL_RGBA makes the textures visible again (just the colors are wrong, as you mentioned).  I'll see about swapping the colors.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 05, 2011, 04:10:11 PM
Anyone know an efficient way to convert a block of BGRA bytes into RGBA?  I could do it with a 'for' loop, take four bytes at a time, do some bit-shifts and & operators to get the color components and then reconstruct them with more bit-shifts and | operators, but I have a feeling that would be really slow..  Anyone have some experience with this before?

--EDIT--
.. or I could just read in four separate bytes and rearrange them, haha..  still I wonder if a for loop is the most efficient way to do this, but at least it doesn't have to be so complicated..
Title: Re: Alpha Testing Underway!
Post by: Mats on November 05, 2011, 04:17:00 PM
i googled it is this to help ? can i post a link ?? ???
Title: Re: Alpha Testing Underway!
Post by: Mats on November 05, 2011, 04:45:04 PM
on the GUI would it be frameskip ? and framelimiter ?? ;D
Title: Re: Alpha Testing Underway!
Post by: Ganster41 on November 05, 2011, 05:36:02 PM
With GLES2Rice I have some perfomance, as with GLES2n64.
PS: I compiled GLES* libraries with Auto-vectorizaton, and unsafe optimization flags(-ffast-math -ftree-vectorize -funsafe-math-optimizations), but can't see any perfomance changes(may be ~1 FPS, but I use my CPU specific flags, like -mtune=arm1136jf-s -march=armv6j too...) :(
Title: Re: Alpha Testing Underway!
Post by: Paul on November 05, 2011, 07:03:14 PM
Finished fixing my two bugs with GLES2Rice.  I've uploaded the latest build and sourcecode (same links as before):

Test APK (http://www.paulscode.com/source/Mupen64Plus-AE/05NOV2011/Mupen64Plus-debug.apk)  (source code (http://www.paulscode.com/source/Mupen64Plus-AE/05NOV2011/mupen64plus-SDL1.3-source.zip))

Now that everything is visible and "RGBAified" properly, I've noticed a couple bugs besides the known shader and texture problems (not sure if you see these too, Kris).  Firstly, the shadows, carpet, etc. in Mario are flickery.  Secondly, things are sometimes sorted incorrectly (the waterfall draws over trees, further-away trees draw in front of closer trees, etc).  It reminds me of the Panter's Algorithm sort problem that you see sometimes for objects with transparency.

Anyway, back to working on the GUI.  I'll have some tests tomorrow (sorry for the delay, everyone who's been waiting)
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 05, 2011, 08:34:18 PM
the rice plugin apparently planted grass in the front hall of the castle  ;)
(http://dl.dropbox.com/u/29967887/Pics/IMG_0251.JPG)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 05, 2011, 08:56:56 PM
Haha, without knowing exactly how the game textures are formatted in Mario64, I would guess that is most likely related to the texture-coordinates bug (other possible causes could be an incorrect index or color format).  I have to say, though, in as little time as it's been since Kris began porting the code to GLES2, I am absolutely amazed at how well it works already!  It took me like six months to get gles2n64 (which was already ported to Android) just to the level of performance that this plug-in is now.
Title: Re: Alpha Testing Underway!
Post by: Kris on November 05, 2011, 09:49:25 PM
Yeah the incorrect sorting is related to alpha test, at the moment the blending usually makes the right bits transparent but it still writes a new depth value. The method of solving this is to discard the fragment but the docs for pretty much every embedded gpu discourage it for perf reasons, still It's what gles2n64 does and how I plan to fix it.

It's cool you've managed to get it running, I released it before it was finished as I was curious if different cpus e.g Cortex-A9 had the same sort of problems, I guess they do. Whilst the coodinates are definatley wrong I think the colours could be slightly off too.

There are some titles that work a bit better than gles2n64, the menus in wipeout are visible and yoshis story and paper mario work a bit better. I'm still wondering if the early Majora's Mask hang is only on my port or if its a fix not in the current source release of n64oid.
Title: Re: Alpha Testing Underway!
Post by: goodboy735 on November 05, 2011, 11:38:28 PM
I'm getting about 4fps higher on my Aria with the rice plugin then I am with gles2n64 :O
And it seems to start up faster too..
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 06, 2011, 12:35:01 AM
On my tablet, pilotwings is slow and nearly stocked in the menue screens.
SGS2 performs slightly faster.
Even on mario, the sound is stuttering heavy.
On Super Smash Bros. the no-eyes-bug is gone.
The light bug in shadowman is not fixed.
Conker's Bad Day on SGS2 has not the big poligons.

My Android TV-Box shows only a black screen.
logcat didn't show an error.

http://db.tt/Y0flMuC2

I'm uploading a video comparsion between tegra 2 OC@ 1600 MHz' without sound plugin and exynos @stock 1200 MHz with sound.
The SGS performs faster.

http://www.youtube.com/watch?v=C1KBVh-V_MQ

How can we configure framskip in rice plugin ? Is the emulator missing the config file for it ?

ps. I'm sure on n64oid it's rice plugin. Why ? All the same bugs. Compare both photos. The lines in the upper right on radar, the messed texture between sky and sea. And on n64oid, there is some stuttering in sound, that wasn't so much under gles2n64.

mupenplus64 - ae
(http://db.tt/uxnOECJw)

n64oid
(http://db.tt/u4l3WkrH)

sorry for the very big pix, but this needs to be illustrated for all.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 06, 2011, 04:21:02 AM
yeah ! ,that was a cind of weird :-S then he need to make the source code official, right ???
Title: Re: Alpha Testing Underway!
Post by: Paul on November 06, 2011, 06:50:30 AM
Well, legally he needs to release the full source code whether he used code from Rice or wrote it entirely himself, because he is distributing it as part of a whole work based on code that's licensed by the GPL.  He is operating on the (incorrect) assumption that he doesn't have to release the source code for pieces he wrote himself, based on the following section of the GPL:

Quote
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections...

The problem with this is that he apparently didn't read the rest of that sentence and the next one:

Quote
...when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

I'm not sure how you can be any more clear about it than that.. But, yeh, you're right.. Yongzh can't even make his argument for keeping the video plug-in closed source if it can be shown that it contains code from another work that's licensed by the GPL.  I think the only Mupen64Plus video plug-in that was released without any license attached was Orkin's original code for GLN64 (subsequent branches, including gles2n64 were all licensed by the GPL).
Title: Re: Alpha Testing Underway!
Post by: Mats on November 06, 2011, 07:51:59 AM
okey  ;D
Title: Re: Alpha Testing Underway!
Post by: Mats on November 06, 2011, 07:54:17 AM
mupen64plus is an open source emulator , right how could n64oid be an closed source emulator, it,s weird  ;D
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 06, 2011, 08:10:56 AM
mupen64plus is an open source emulator , right how could n64oid be an closed source emulator, it,s weird  ;D

yonghz took mupen64plus's open source code, changed it to make n64oid and kept most of the changes to himself therefore making a it a closed source emulator (partially closed source anyway)
Title: Re: Alpha Testing Underway!
Post by: Mats on November 06, 2011, 08:13:05 AM
okei :-D
Title: Re: Alpha Testing Underway!
Post by: Mats on November 06, 2011, 08:35:40 AM
would it be frameskip on the gui ? ;D
Title: Re: Alpha Testing Underway!
Post by: Paul on November 06, 2011, 09:13:21 AM
would it be frameskip on the gui ? ;D
eventually
Title: Re: Alpha Testing Underway!
Post by: Paul on November 06, 2011, 10:16:19 AM
It's cool you've managed to get it running, I released it before it was finished as I was curious if different cpus e.g Cortex-A9 had the same sort of problems, I guess they do. Whilst the coodinates are definatley wrong I think the colours could be slightly off too.

I definitely appreciate you releasing the code even if it isn't complete yet.  I'm sure I speak for everyone when I say it's always great to see the results of someone's hard work.  Keep us posted!  You're definitely a more experienced developer than I am when it comes to GL, but I'll see if I can help fix any of the remaining problems once I finish writing my GUI.

I'm still wondering if the early Majora's Mask hang is only on my port or if its a fix not in the current source release of n64oid.

I'll give it a try, one sec.  That's one of the games I own.. I've been trying to stay legal by only keeping ROMs on my computer that I bought the actual N64 cartridge.  I own a large library of N64 games, and I'll buy any that I don't have if needed to solve game-specific problems (such as Dobutsu no Mori, which I bought on Ebay before working on the EPROM clock emulation component recently).

--EDIT-- Emulation freezes on Mupen64Plus AE too, after walking through one of the forest exits.
Title: Re: Alpha Testing Underway!
Post by: Kris on November 06, 2011, 11:23:06 AM
The alpha test issue was quite simple to fix you can try it here (https://www.box.net/shared/37o2ii3c049mrb87aajo), there are still some related issues remaining. I'd keep the current OGLGraphicsContext that your using there's only changes in 3 or 4 files.

Thanks for the info about Zelda, I've haven't had a good look for the cause yet.

Rice stores its settings in mupen64plus's own config I think, but mine is empty, passing --savesettings might work. There is an option to skip every other frame not much else and I don't know if it works.

Also at the top of OGLDebug.h there is #define OPENGL_DEBUG this checks for errors after most gl calls and should probably be removed for release builds.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 06, 2011, 12:48:58 PM
The alpha test issue was quite simple to fix you can try it here (https://www.box.net/shared/37o2ii3c049mrb87aajo), there are still some related issues remaining.

Thanks!  I finished incorporating the alpha test changes.  You were right about performance being affected (Mario64 drops to about 15 FPS)
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 06, 2011, 04:28:05 PM
Cant wait for the plugin to be working ;)
then kirby 64 should actually work
Title: Re: Alpha Testing Underway!
Post by: Paul on November 06, 2011, 06:37:57 PM
So I finally figured out why I'm having problems with the state changes (haven't figured out the solution yet though).  What happens is a notification icon goes into the status bar, with the intent to start the SDLActivity.  When you press home, the emulator pauses, and the app instance goes into the background.  So far everything is fine.  Then, pressing the notification icon starts the SDLActivity like it's supposed to, BUT IT'S NOT THE SAME APP INSTANCE!  In other words, the emulator ends up running twice (the original instance is still paused and in the background).  It's a completely new sandbox - it loads the libraries up again and everything, and all of the static variables are reset.  There is no interaction at all between the two instances.

I'm sure the solution to this problem is in the sourcecode that Epic_bubble pointed me to.  I just have to study it a little closer to figure out what I'm doing differently.  At least now that I know WHAT the problem is, I'll have a better chance of solving it.

--EDIT-- Ok, I think I know what's wrong.  Looks like I have to set a couple flags in my status bar notification:
Code: [Select]
notification.flags = Notification.FLAG_ONGOING_EVENT | Notification.FLAG_NO_CLEAR;   
 notificationIntent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP);
And then set another attribute in the manifest:
Code: [Select]
android:launchMode="singleTask"Not sure if that's everything, but I'll see if that helps..

--EDIT 2-- Darn, that didn't fix it.  More digging, I guess..

--EDIT 3--Ha!  I got it.  I was also using the wrong context when set the notification's "last event info".  The app resumes and the emulation starts back up.  Unfortunately, there is still a problem - it goes into a black screen.  I'm pretty sure this is related to the following message in logcat:
Code: [Select]
11-06 20:31:00.355: DEBUG/PhoneWindow(18610): couldn't save which view has focus because the focused view paulscode.android.mupen64plus.SDLSurface@4050f8c0 has no id.This message has been around since I started the app, but I never got around to figuring out how to give the SDLSurface an ID.  Time to do some googling..

--EDIT 4--Ok, fixed the ID problem, but still a black screen on resume :(  I'm thinking maybe it is something to do with the GL context.  I'll have to do more digging tomorrow after work.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 07, 2011, 01:05:37 AM
i cant wait :-D
Title: Re: Alpha Testing Underway!
Post by: Mats on November 07, 2011, 02:42:46 AM
will the emulator go slower with the gui ? and all they tests with the other video plugin doesnt work :-(  on xperia x8 armv6 600mhz :(
Title: Re: Alpha Testing Underway!
Post by: koekje on November 07, 2011, 04:32:51 AM
I think the GUI will not affect the speed of the emulator since it has nothing to do with the graphics plugin.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 07, 2011, 04:40:27 AM
will the emulator go slower with the gui ?
No, the GUI is a separate component which will not be running while the emulator is running.  It will use some memory of course, but that shouldn't affect anything.

and all they tests with the other video plugin doesnt work :-(  on xperia x8 armv6 600mhz :(
What does the app do specifically?  Could you post a logcat output after experiencing the problem?
Title: Re: Alpha Testing Underway!
Post by: Mats on November 07, 2011, 05:28:00 AM
The app wont start it goes to black screen in 8 sec and the app shuts down.it with gles2n64 plugin and with the other. to
say it easy the app like is over 2 mb doesnt
start :-(
Title: Re: Alpha Testing Underway!
Post by: Paul on November 07, 2011, 03:42:48 PM
It is crashing while attempting to load the video plug-in.  I expect this is because of the VFP flags I added.  I'll remove them since they didn't really improve performance.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 07, 2011, 03:46:14 PM
It is crashing while attempting to load the video plug-in.  I expect this is because of the VFP flags I added.  I'll remove them since they didn't really improve performance.
Thanks so it will work then ?
Title: Re: Alpha Testing Underway!
Post by: Paul on November 07, 2011, 08:10:40 PM
I fixed one problem with the Activity resume code.  It seems that SurfaceView.surfaceDestroyed is called when the home button is pressed, which means that it needs to be recreated on resuming the Activity.  On resuming, surfaceCreated and surfaceChanged are called, and the EGL context is lost.  To work around this, I called initEGL again to create a new EGL context.  Unfortunately, I still have a black screen, so the problem is not fixed yet.  I've been using the code for fceudroid for comparison, but I can't see what I'm doing differently.  There aren't any error messages - just a black screen.  The problem isn't specific to the SurfaceView and the EGLSurface - the virtual gamepad (an extension of plain old View) is also not visible.  I'm definitely scratching my head on this one.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 08, 2011, 05:37:30 AM
could you make a test without vfp flags ?
Title: Re: Alpha Testing Underway!
Post by: koekje on November 08, 2011, 04:13:25 PM
Hey Paul, the rice port is not finished right?

Crualfoxhound just posted something on FPSE forum that the new version of N64oid will have high res texture support and it works great according to him.
Title: Re: Alpha Testing Underway!
Post by: Ganster41 on November 08, 2011, 04:21:01 PM
Hmm, and why emulator work on my device with same CPU, as in X8? May be problem in Android version/screen resolution?
Title: Re: Alpha Testing Underway!
Post by: crualfoxhound on November 08, 2011, 04:26:06 PM
Yes hi Res pack support on n64oid work brilliant.
Hunt for the texture pack. I think I had all mine from emutalk
Download,extract the folder, place the folder in n64oid-hires_textures on SD card
same place you find you save,config,folders.
then load the game and enjoy new textures
Just awsome.

Catch ya later..
Title: Re: Alpha Testing Underway!
Post by: koekje on November 08, 2011, 04:29:53 PM
Wow thats realy nice :o love to see that update coming :p i tought the rice plugin was still in development :p cool!

Any ETA on when the update comes?
Title: Re: Alpha Testing Underway!
Post by: Paul on November 08, 2011, 04:47:08 PM
Any chance of Yongzh updating SourceForge?   ;)
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 08, 2011, 05:04:10 PM
Yes hi Res pack support on n64oid work brilliant.
Hunt for the texture pack. I think I had all mine from emutalk
Download,extract the folder, place the folder in n64oid-hires_textures on SD card
same place you find you save,config,folders.
then load the game and enjoy new textures
Just awsome.

Catch ya later..

Hey crualfoxhound thats awesome news. Do the high res texture packs have an impact on performance? I guess that they would.
Title: Re: Alpha Testing Underway!
Post by: SpawnHyuuga on November 08, 2011, 05:40:31 PM
I would pay for this app if you can put some speed into it for ARMv6 devices. I don't know if it's the processor or just the idea of "ARMv6" (I'm kind of a dunce about hardware) - but my PSP was fairly good at running N64 games and it had 333 MHz maximum.

My phone has 800 MHz so I was almost expecting better speed. Great work on this though; I hope to see it shine.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 08, 2011, 06:15:06 PM
I would pay for this app if you can put some speed into it for ARMv6 devices. I don't know if it's the processor or just the idea of "ARMv6" (I'm kind of a dunce about hardware) - but my PSP was fairly good at running N64 games and it had 333 MHz maximum.

My phone has 800 MHz so I was almost expecting better speed. Great work on this though; I hope to see it shine.

To be fair the n64 emulator for the psp isnt very good, but its runs surprisingly well for the low power of the psp. The only game I ever got to run perfect with sound was super mario 64, most other games needed the sound plugin disabled.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 08, 2011, 06:51:24 PM
The main thing that's dragging on performance is, of course, the video plug-in.  I don't know how video is handled on the PSP N64 emulator, but I would assume it is super optimized for that specific device it runs on.  I really think the emulator could see a big improvement in performance by porting a light-weight video plug-in like Arachnoid to GLES1, even if it isn't as pretty.  There are other optimizations that can be done for specific devices or at the cost of compatibility or other things (it's open source, so anyone can create their own customized version).  For example, the core could be sped up by using the native memory location for RDRAM if there is nothing already there, and getting rid of the trampoline code by halving the target memory in the .bss section.  Also, an audio plug-in that utilizes SLES would improve performance by adding hardware-mixed audio rather than software-mixed that happens in the Android SDL port.  If we get some assembly developers into the mix, there are a lot of things that could be optimized throughout the code.  The SDL dependency could also be completely removed, having video and audio handled entirely by the Android API.  And of course compiling with the VFP, auto vectorization, and unsafe math optimization flags.  In the end, a lot of small optimizations can potentially add up to a really big one.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 08, 2011, 07:08:33 PM
It might be good to have a chat with the main guy of the n64 psp emulator you might be able to share some useful information between each other, his online name is Kreationz and his forum is here: http://forums.daedalusx64.com/

And your right about the heavy optimisations, ive been following the deadelusx64 project for along time and it has improved dramatically since I first used it about 3 years ago, back then games were hardly playable even with the sound plugin disabled.

Also this probably isnt useful but heres the source to the n64 emulator for the wii/gamecube, it works really well actually. http://code.google.com/p/mupen64gc/
Title: Re: Alpha Testing Underway!
Post by: Paul on November 08, 2011, 07:43:09 PM
I'd expect to say something similar in 2 or 3 years about this project and it's branches.  Initially, focus is probably going to be almost exclusively on bug-fixes and ROM compatibility.  Once that eventually plateaus, I think the main focus will naturally shift to features and optimizations, slowly improving the emulator over time.  That is, of course, assuming it doesn't die a quiet death due to lack of interest (I don't really see that happening, but who knows?)
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 08, 2011, 07:50:49 PM
I expect interest to have a huge increase after the GUI, It may still not attract new devs but it will definitely attract new users and whenever it ends up on the android market I expect the interest to rise to its peak since non tech savvy users can install it without having to fiddle with their settings to install a non market apk (it might be a good idea to provide some sort of in app documentation on how to put roms into the emulator when you reach this point).
Title: Re: Alpha Testing Underway!
Post by: Paul on November 08, 2011, 08:00:32 PM
could you make a test without vfp flags ?

Have you tried one of the earlier builds?  I think the 2 November build (http://www.paulscode.com/source/Mupen64Plus-AE/05NOV2011/Mupen64Plus-debug.apk) was before I changed the compiler flags.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 08, 2011, 08:07:10 PM
Just to let everyone know, I have a big test on Thursday, so I probably won't be doing much development until then (I always cram before a test, even though everyone says not to, haha)  I plan to make a serious effort to finish the GUI this weekend (assuming I can solve the black-screen-on-resume bug).  The next phase will be testing, debugging, and adding menu options, and I'd like to be there by next week if at all possible.
Title: Re: Alpha Testing Underway!
Post by: dustarma on November 08, 2011, 08:56:38 PM
could you make a test without vfp flags ?

Have you tried one of the earlier builds?  I think the 2 November build (http://www.paulscode.com/source/Mupen64Plus-AE/05NOV2011/Mupen64Plus-debug.apk) was before I changed the compiler flags.

The November 5 build still has the VFP flags, right?

Because that version is running fine on my X10 Mini and it uses the same chipset as the X8, in fact IIRC the X8 and X10's CPU should support VFP.
Title: Re: Alpha Testing Underway!
Post by: Ganster41 on November 09, 2011, 01:55:47 AM
I want to try compile emulator with completely hard float, with GCC 4.6 :)
Just installed alternative NDK build, may be in the evening I'll try...
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 09, 2011, 02:07:54 AM
I want to try compile emulator with completely hard float, with GCC 4.6 :)
Just installed alternative NDK build, may be in the evening I'll try...

Just a heads up to look at the opening post on how to compile it, you have to do it a certain way or you will get the ram full of zeros bug (forces the game to be stuck on a black screen).
Title: Re: Alpha Testing Underway!
Post by: Mats on November 09, 2011, 06:33:39 AM
could you make a test without vfp flags ?

Have you tried one of the earlier builds?  I think the 2 November build (http://www.paulscode.com/source/Mupen64Plus-AE/05NOV2011/Mupen64Plus-debug.apk) was before I changed the compiler flags.
  no it didnt work here is the logcat output :
Title: Re: Alpha Testing Underway!
Post by: Paul on November 09, 2011, 10:55:15 AM
no it didnt work here is the logcat output :

Did any version work, or have you always had this problem?  (I deleted the archived threads, so I don't recall if you ever reported it working)  The other possible cause is your device doesn't have GLES2 installed.  If you aren't sure, you can install the app "Android System Info", and go to the "OpenGL" section under the "System" tab.  If your device supports GLES2, it should say supported versions 2.0 and CM 1.1.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 09, 2011, 11:56:37 AM
no it didnt work here is the logcat output :

Did any version work, or have you always had this problem?  (I deleted the archived threads, so I don't recall if you ever reported it working)  The other possible cause is your device doesn't have GLES2 installed.  If you aren't sure, you can install the app "Android System Info", and go to the "OpenGL" section under the "System" tab.  If your device supports GLES2, it should say supported versions 2.0 and CM 1.1.
open gles 2.0 and cm 1.1 stays it and all the builds before the package got 2 mb works and the last build that work is : ARM6, VFP Test
This will break the emulator on ARM5
devices (there doesn't seem to be a
provision for specifying an ARM6-only build
in the Android makefiles - it lumps ARM6
and ARM5 together under the heading
"armeabi").
Everyone with an ARM6 device, please run
this test and let me know if it has any effect
on performance (better, worse, or no
noticeable change)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 09, 2011, 04:59:04 PM
Oh, well if that one worked, then it must just be taking up too much memory to load both libgles2n64.so and libgles2rice.so.  It that's the problem, it should correct itself when I add the part of the GUI for choosing plug-ins (there's no reason to have both in memory since I can only attach one to the core at a time anyway).
Title: Re: Alpha Testing Underway!
Post by: Ganster41 on November 09, 2011, 05:07:23 PM
Wow, compiling with hard float is very hard. All external libs (ex. gcc lib, stlport, stdc++...) need to be compiled with hard float flags too  :o
I compile all libraries(except core) with GCC 4.6.2, configured globally(in toolchain settings) for ARMv6 CPU, with flags -O3 -ffast-math -ftree-vectorize -march=armv6j -mtune=arm1136jf-s -mfloat-abi=softfp -mfpu=vfp
And get little speed-up. 14-17 FPS(15-16 FPS most often) in Mario64 with libgles2n64. libgles2rice was compiled incorrectly, and unusable(most textures are invisible)...
Title: Re: Alpha Testing Underway!
Post by: Mats on November 10, 2011, 07:41:22 AM
Oh, well if that one worked, then it must just be taking up too much memory to load both libgles2n64.so and libgles2rice.so.  It that's the problem, it should correct itself when I add the part of the GUI for choosing plug-ins (there's no reason to have both in memory since I can only attach one to the core at a time anyway).
ok ! :D that was good news  ;)
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 10, 2011, 12:24:06 PM
"the other" emulator has now support for high-res textures.
i see, there are a few good projects for game textures.
would be a nice feature for mupen64plus - ae in the near future.  :)

http://www.youtube.com/watch?v=WuY0F2fxzFk

Back to topic :  ;D
Funny bug on rice plugin on Mario Kart64. You can see the cars in front, and they drive backwards.
(http://db.tt/Y4ADbT6h)
Title: Re: Alpha Testing Underway!
Post by: Mats on November 10, 2011, 02:22:02 PM
"the other" emulator has now support for high-res textures.
i see, there are a few good projects for game textures.
would be a nice feature for mupen64plus - ae in the near future.  :)

http://www.youtube.com/watch?v=WuY0F2fxzFk

Back to topic :  ;D
Funny bug on rice plugin on Mario Kart64. You can see the cars in front, and they drive backwards.
(http://db.tt/Y4ADbT6h)
haha !  :D cool
Title: Re: Alpha Testing Underway!
Post by: Paul on November 10, 2011, 04:20:13 PM
would be a nice feature for mupen64plus - ae in the near future.  :)
Should be possible once GLES2Rice is complete (the hires stuff will just need to be uncommented and debugged once the rest of the plug-in is running well).

Funny bug on rice plugin on Mario Kart64. You can see the cars in front, and they drive backwards.
Most of the depth problems in your screenshot should be fixed now in the latest version (I'd post an update, but the project is a bit torn apart at the moment, as I'm in the middle of incorporating the GUI stuff that I had going on a separate code branch).  Not sure if that will have any effect on the backwards cart though, haha!
Title: Re: Alpha Testing Underway!
Post by: Mats on November 11, 2011, 09:10:41 AM
how to make the source code to an .apk file ?? when i use eclipse its someting wrong with the androidmanifest.xlm ? some steps ??
Title: Re: Alpha Testing Underway!
Post by: Paul on November 11, 2011, 10:00:41 AM
I've actually just been building from the command prompt to build this project, due to the RAM full of zeros bug, which prevents you from having a single project.  I've only been using Eclipse for the debugging tools.  It should be fairly simple to turn it into an Eclipse project, but you'd have to solve the RAM full of zeros bug first.

Anyway, to build from the command prompt:

1 ) Unzip the sourcecode archive
2 ) Go to the mupen64plus-core-ARCHs folder
3 ) Run the command 'ndk-build'
4 ) Go to the mupen64plus-SDL1.3 folder
5 ) Run the command 'ndk-build'
6 ) Swap the libraries (see the initial post for their locations - there are 4 copy/pastes you need to do)
7 ) Run the command 'ant debug'
8 ) If your device is set up as the development device, run the command 'ant install'
     Otherwise install the .APK manually (it will be in the 'bin/' subfolder)
Title: Re: Alpha Testing Underway!
Post by: Mats on November 11, 2011, 10:28:14 AM
I've actually just been building from the command prompt to build this project, due to the RAM full of zeros bug, which prevents you from having a single project.  I've only been using Eclipse for the debugging tools.  It should be fairly simple to turn it into an Eclipse project, but you'd have to solve the RAM full of zeros bug first.

Anyway, to build from the command prompt:

1 ) Unzip the sourcecode archive
2 ) Go to the mupen64plus-core-ARCHs folder
3 ) Run the command 'ndk-build'
4 ) Go to the mupen64plus-SDL1.3 folder
5 ) Run the command 'ndk-build'
6 ) Swap the libraries (see the initial post for their locations - there are 4 copy/pastes you need to do)
7 ) Run the command 'ant debug'
8 ) If your device is set up as the development device, run the command 'ant install'
     Otherwise install the .APK manually (it will be in the 'bin/' subfolder)
Thanks im gonna try later :-D
Title: Re: Alpha Testing Underway!
Post by: Mats on November 11, 2011, 10:39:01 AM
do you think mupen64plus ae will run at full speed some time at 600MHz armv6?
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 11, 2011, 11:50:27 AM
do you think mupen64plus ae will run at full speed some time at 600MHz armv6?

it goes almost perfectly with me (super mario 64), i suggest you to go in airplane mode, a lot things go 10 times better with it, you just have to wait paul to improve the code, this emulator is too fast to be an alpha, that means it will run perfectly in 600MHz Smartphones (i have an Lg Optimus One)

-------------------------
Buttons Idea For Paul: The Z Button Would Fit Better In The Down Center, Letting Us Use It When We Need It (It's really  hard to use it in sm64) and letting you put the r button in it
Also a moving analog stick when the emulator reaches a final version would be a better thing to add, it would let us see where precisely the analog aims

P.s:the A and B buttons could be bigger, they don't always respond in HVGA screens

Title: Re: Alpha Testing Underway!
Post by: Mats on November 11, 2011, 12:28:56 PM
thanks it runs now on full speed but the sound is choppy
Title: Re: Alpha Testing Underway!
Post by: Paul on November 11, 2011, 12:41:29 PM
do you think mupen64plus ae will run at full speed some time at 600MHz armv6?
In a year or two, I'd expect it to run a lot better.  Optimizations will most likely be slow to develop, so I wouldn't get my hopes up too high in the short-term.  It will most likely improve slowly over time as developers figure out better ways of doing various things to improve performance.

thanks it runs now on full speed but the sound is choppy
Minor audio skipping should take less time to improve than noticeable loss of frame-rate.  I might move the SLES audio plug-in higher on my priority list, since this optimization could be enough of a boost to fix some of the less serious choppy-audio problems with Mario on older devices and Zelda on newer ones.

Buttons Idea For Paul: The Z Button Would Fit Better In The Down Center, Letting Us Use It When We Need It (It's really  hard to use it in sm64) and letting you put the r button in it
Also a moving analog stick when the emulator reaches a final version would be a better thing to add, it would let us see where precisely the analog aims

P.s:the A and B buttons could be bigger, they don't always respond in HVGA screens

The gamepad layouts are completely customizable, just take a look in the skins/gamepads folder.  I can help you figure out the syntax if you have trouble.  At some point I'll document it a little better, but you should be able to figure it out by studying the existing layouts.  I will be changing the syntax for the analog stick (using the code I came up with for the Xperia Play touchpads, which works a whole lot better).  Gamepad layouts are one of the areas I expect to see a lot of contributions from folks once this project starts getting a lot more attention during the Beta Testing phase (coming soon, after I finish the GUI hopefully in the next week or so).
Title: Re: Alpha Testing Underway!
Post by: koekje on November 11, 2011, 01:32:27 PM
Are you going to put the emulator on slideme to? I dont have a credit card and slideme offers a paypal option.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 11, 2011, 01:36:35 PM
Are you going to put the emulator on slideme to? I dont have a credit card and slideme offers a paypal option.
its going to be free no matter what  8) ;D 8)
Title: Re: Alpha Testing Underway!
Post by: koekje on November 11, 2011, 01:40:47 PM
I thought i heard him say he was going to put in on the market for 1 dollar but you could also compile the apk for free if you want
Title: Re: Alpha Testing Underway!
Post by: Paul on November 11, 2011, 02:03:50 PM
It will be listed for $1 on the market, but free here.  You won't have to compile it, I'll have the compiled APK here for anyone who isn't a developer.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 11, 2011, 02:57:58 PM
It will be listed for $1 on the market, but free here.  You won't have to compile it, I'll have the compiled APK here for anyone who isn't a developer.
smart. Make them visit your website.  ;)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 11, 2011, 03:16:07 PM
Well, I'm sure someone will list a free build on the market anyway.  I might even list it twice myself.  The main reason I'd like folks to come here is so they can get involved in the project.  I'm planning to rearrange the forum a bit to create an entire section for the emulator, with boards for support, developers, ROM compatibility, etc.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 11, 2011, 03:26:27 PM
Well, I'm sure someone will list a free build on the market anyway.  I might even list it twice myself.  The main reason I'd like folks to come here is so they can get involved in the project.  I'm planning to rearrange the forum a bit to create an entire section for the emulator, with boards for support, developers, ROM compatibility, etc.
this goes better and better :)
Title: Re: Alpha Testing Underway!
Post by: Mats on November 11, 2011, 04:08:22 PM
is it hard to write the GUI ? :)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 11, 2011, 04:46:22 PM
is it hard to write the GUI ? :)

No, it's quite simple -- written in Java, with an easy-to-understand API.  The only difficulty I'm having at the moment is restoring the SDL surface after leaving then returning.  Once I get that figured out, it will just be a matter of testing on some other phones, then adding whatever features and options I want to have in the menu system.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 11, 2011, 04:57:01 PM
is it hard to write the GUI ? :)

No, it's quite simple -- written in Java, with an easy-to-understand API.  The only difficulty I'm having at the moment is restoring the SDL surface after leaving then returning.  Once I get that figured out, it will just be a matter of testing on some other phones, then adding whatever features and options I want to have in the menu system.
ok will the menus look like in n64oid:)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 11, 2011, 05:33:09 PM
No idea.  I don't own N64oid (didn't want to be accused of copying it).
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 11, 2011, 09:29:10 PM
A couple days after every n64oid update, slideme.org's website slows to a grinding halt. Coincedence?
Title: Re: Alpha Testing Underway!
Post by: koekje on November 12, 2011, 02:23:54 AM
Well they got more than 100000 downloads so if every one tries to download the new update at once i think slideme just goes black for a couple of hours xd
Title: Re: Alpha Testing Underway!
Post by: Mats on November 12, 2011, 04:22:03 AM
is this site to help with the gui ? speckyboy.com/2010/05/10/android-app-developers-gui-kits-icons-fonts-and-tools/
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 12, 2011, 08:16:14 AM
The gamepad layouts are completely customizable, just take a look in the skins/gamepads folder.  I can help you figure out the syntax if you have trouble.  At some point I'll document it a little better, but you should be able to figure it out by studying the existing layouts.  I will be changing the syntax for the analog stick (using the code I came up with for the Xperia Play touchpads, which works a whole lot better).  Gamepad layouts are one of the areas I expect to see a lot of contributions from folks once this project starts getting a lot more attention during the Beta Testing phase (coming soon, after I finish the GUI hopefully in the next week or so).

so that means you will include a settings zone letting you customize the controls's size, position and maybe skin when you finish the GUI?if you do, you should add a way to save custom positions etc... for a game, setting automatically the buttons.
also i'm encountering a bug: the analog stick's indicator doesn't move  ( i can move my character but the analog doesn't)
Is there a way to use the analog style control instead of the one with no analog?
is there a way to see fps? i'm trying to find out how to improve performance
if you can, can you tell me step by step how to put the analog in the top left part of the screen? i have a semi multitouch phone so sometimes it glitches with analog in the down left and a button doesn't work or it presses random buttons.
this emulator is a pre alpha, IT'S GOING TOO FINE, NOT EVEN SNES EMULATORS GO THAT FAST! (in fact snes emulators lag a lot here)
keep up the good work!!
Title: Re: Alpha Testing Underway!
Post by: Paul on November 12, 2011, 09:13:47 AM
so that means you will include a settings zone letting you customize the controls's size, position and maybe skin when you finish the GUI?
In the GUI, you will be able to import custom gamepad layouts.  The layouts can be made by anyone (doesn't require any programming skill).  They will not be created or customized through the GUI itself.  I will probably make a "skin builder" program at some point, but for now it's easy enough to create the gamepad layouts without one.

the analog stick's indicator doesn't move  ( i can move my character but the analog doesn't)
This is intentional.  By not redrawing the analog "stick", there is a noticeable performance improvement on some devices.  I'll be using this layout by default until I develop a faster way to redraw the onscreen gamepad (probably using GLES directly rather than the Android API in Java).

Is there a way to use the analog style control instead of the one with no analog?
Yes, you can edit the file [sdcard]/app-data/paulscode.android.mupen64plus/skins/gamepads/gamepad_list.ini.  Move the layout you want to use to the top of the list.  Choose one of the "analog" layouts instead of the "touch" layouts (probably Mupen64Plus-AE-Analog).  This will be a function of the GUI, but for now the layout has to be chosen using the config file.  You can also iterate through the layouts with the search button if your device has one, but there is a bug with that (where the buttons disappear and the analog control freezes and gets drawn to the wrong part of the screen)

is there a way to see fps? i'm trying to find out how to improve performance
For now, FPS is being written to the logcat output every 30 frames.  The next official build will have an optional FPS object that you can add to the gamepad layouts, which can be turned on or off from a GUI option.  The syntax will look like this (in the layout's pad.ini file):

Code: [Select]
[FILENAME]
info=FPS
x=0
y=0
refresh=30

That would put the FPS at the top-left of the screen and it would refresh every 30 frames.  Filename will be a .PNG file to use for the background of the FPS counter (can be completely transparent for no background), and the numbers will be centered on that image.

this emulator is a pre alpha, IT'S GOING TOO FINE
Well the project has progressed quite a bit.  When this phase of testing began, the graphics were completely screwed up, it crashed after running for a minute, there was no way to map non-standard Android buttons, etc (read the first post in this thread to see all the problems that have been fixed).  It is nearing the end of what I'm calling the "alpha-testing phase" - I just want to have a working GUI in place first.  The beta-testing phase will mainly focus on ROM-specific and video plug-in problems (the alpha-testing phase has been mainly focused on getting the basic skeleton of the emulator in place, and getting the plug-ins to emulate Mario64 as accurately as possible on as many devices as possible)
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 12, 2011, 12:13:55 PM
all paul said
That's awesome, i never saw an emulator with all that support!
by the way i can't seem to set hardware buttons becuse the code doesn't show, what happened? it was working in older builds (in fact i found this emulator yesterday from the XDA developers forum, and i see all the changes from that version to this) and in order to play mario 64 better, i need to bind the a button and z button, i'm currently testing all mario 64 (completing all the game) to check if there are any bugs, i really want to support this emulator in any way, but i can help just with ideas or doing buttons with vectorial programs, i think this will be the best android n64 emulator ever :D
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 12, 2011, 12:21:12 PM
Quote
by the way i can't seem to set hardware buttons becuse the code doesn't show, what happened?

you need the SDL scancode finder from the first post. just run it to find out the keycodes.
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 12, 2011, 01:26:23 PM
Quote
by the way i can't seem to set hardware buttons becuse the code doesn't show, what happened?

you need the SDL scancode finder from the first post. just run it to find out the keycodes.


Thanks, this will speed up my SM64
---
I just found out why the sound gets these "spikes": this happens when the emulator lags, this could be fixed eith a plugin similiar as pcsx2's sound plugins (there's one letting you get normal speed audio even if the game lags, but it could crash games)
P.s:because i own a n64  and i own 3 of the most selled games (sm64, mario kart 64 and 007 goldeneye)+ other famous games i could test, i could compare the ones on the console and the ones on the android to check bugs :D
Title: Re: Alpha Testing Underway!
Post by: Paul on November 12, 2011, 03:35:56 PM
I just found out why the sound gets these "spikes": this happens when the emulator lags, this could be fixed eith a plugin similiar as pcsx2's sound plugins (there's one letting you get normal speed audio even if the game lags, but it could crash games)

I'm not sure how that would work - the gaps are due to the fact that the audio is playing at a faster rate than the emulation can keep up with.  I could buffer the audio, but then you don't just have to deal with latency depending on the size of the buffer, but the buffered audio will still continuously "catch up" to the emulation and have to be re-buffered, causing fewer larger gaps in the audio instead of numerous smaller gaps.  The only other implementation I can think of would be to dynamically change the sample-rate of the audio playback, so that it always matches the emulation speed, but that could get really annoying for games where the frame-rate changes a lot depending on the 3D scene like Zelda64 (the music would be constantly changing pitch).  Ultimately, I think the only acceptable way to solve this is to just keep adding optimizations to the emulator over time, until it runs most games at full-speed so there aren't audio spikes in the first place.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 12, 2011, 04:07:07 PM
I think I've figured out how to solve the black-screen on return bug.  I believe I can keep the thread that's running the emulator separate, recreate the SDLSurface from scratch, and hand it the emulator's thread.  This will create a new EGL context, so I'll need to figure out how to make sure the video plug-in can still link with it.  I'll see how it turns out..
Title: Re: Alpha Testing Underway!
Post by: Paul on November 12, 2011, 08:56:19 PM
Aha!  I got it working.  It doesn't always behave the way I want it to yet, but it resumes, which was the main snag I've been dealing with.  I ended up having to do a save-state and shut down the core entirely.  Then I recreate the SDL context on resume, start the emulator, and load-state.  It's a bit sluggish, but it works.  I'll come back to this at some point in the future, because I am sure it is possible to do this by just pausing the emulator rather than going through the whole complex thing.  But it's good enough for now - I can finally move on to other parts of the GUI.

Before I get too excited, though, I better have some folks test this on other phones to make sure it doesn't have that ANR crash bug (in particular on Tegra 2, but potentially on some other devices like the Xperia Play which are more sensitive to delays in the main UI thread than my Droid X is).

Resume App Test (http://www.paulscode.com/source/Mupen64Plus-AE/12NOV2011/Mupen64Plus-debug-resume.apk)

Provide the logcat output after doing the following test:
1) Run the app and let it load for a bit
2) Press the "Home" button
3) Relaunch from the status-bar
4) Press the "Menu" button and choose "Close"
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 12, 2011, 09:27:12 PM
See what you can get from this. I triee multiple times and when.u reload it the first time from the status bar it crashes but every time. After that it loads the auto save thing. Save states work
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 13, 2011, 12:23:44 AM
ok

tegra 2 tablet and phone with rice plugin.
after pressing home, the sound continues. go back to app, no menue. then the app shuts down with fc.
if i start the game again, it doesn't begin with mario's face, it starts in the menue screen.

logcat tablet
http://db.tt/La8TwyqL

traces.txt
http://db.tt/rvK45tgP

logcat from gles2n64
http://db.tt/C6lwE424

on sgs2 :
it's the same bug.
logcat exynos_mali
http://db.tt/HoCUiJNC

taces.txt
http://db.tt/IsB5WEOd

logcat from gles2n64
http://db.tt/C6lwE424

it works only with gles2n64
Title: Re: Alpha Testing Underway!
Post by: goodboy735 on November 13, 2011, 01:29:43 AM
HTC Aria:
gles2n64: resumes fine
gles2rice:
With it running I hit home, it closes with the notification there and if I hit it right after, it reloads the game and resumes.. but if I wait at the homescreen for a bit, I hear the audio resume, and when I tap the notification it instantly resumes already loaded (with the audio playing)...
Either way, when it resumes input doesn't work and android pops up with the not responding box after a bit (even though its rendering video and sound).. if I force close it the notification is still there, and when tapped on it loads and resumes with input working fine..

Logcat: http://dl.dropbox.com/u/1077120/mupentesting/logcat_resumetest.txt

Hope this was easy enough to read :P I can probably record a video if needed..

E: just tried this on the Moto Flipside and rice doesn't even load! black screen...sound doesn't start either. Onscreen controls and GUI are fine.. resuming still acts the same as the Aria...
Logcat from Flipside starting up with rice plugin: http://dl.dropbox.com/u/1077120/mupentesting/logcat_flipside_rice.txt


Title: Re: Alpha Testing Underway!
Post by: Mats on November 13, 2011, 04:25:07 AM
it doesn't start could you make the same test without the rice plugin : )
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 13, 2011, 04:33:05 AM
if you didn't enable the rice plugin, libgles2n64.so is selected as default.
if you have enabled rice, you must change the config, like you did before.
it's well explained in the first post.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 13, 2011, 04:35:56 AM
if you didn't enable the rice plugin, libgles2n64.so is selected as default.
if you have enabled rice, you must change the config, like you did before.
it's well explained in the first post.
paul says it takes to much memory to loade both. and i need to wait to the GUI is finish.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 13, 2011, 05:42:24 AM
Seems to work for me but only every second time. First time I tap the status bar icon it just seems to hang for a second and kicks me back to the homescreen and the second time it works and reloads the save state. The close option in the emulator also works fine.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 13, 2011, 06:36:27 AM
Wow, gotta love all the different behaviors.  I'm pretty sure this is all related to that ANR bug, which either causes a crash or a restart (which screws with the desired behavior).  I'll see if there is any way to speed up the process or move things to a separate thread.  Sure would be nice if at least the base operating system would behave consistently on different devices..
Title: Re: Alpha Testing Underway!
Post by: Paul on November 13, 2011, 07:15:44 AM
To be honest, I had only tested this with gles2n64, since gles2rice is not really complete yet.  I just tested it with gles2rice, and my phone has a similar behavior, where it just continues running after I press home, and key input gets locked out on resume.  It doesn't seem to be a problem with "Save" and "Load" functions, though, because they work fine on my phone.  Since it seems to have more problems when using gles2rice, I'll start by getting it working on my phone when using that plug-in.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 13, 2011, 11:41:36 AM
the test works not whats the problem ?
Title: Re: Alpha Testing Underway!
Post by: Paul on November 13, 2011, 12:01:09 PM
whats the problem ?
The problem is that I'm spending too much time starting up and/or shutting down on the main UI thread which Android refuses to accept.  I'd guess the reason it affects gles2rice more is that it's more CPU intensive than gles2n64 so it's delaying the UI thread even more.  I think the solution is to move most of the work to another thread.  I'm working on this idea now.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 13, 2011, 02:27:45 PM
whats the problem ?
The problem is that I'm spending too much time starting up and/or shutting down on the main UI thread which Android refuses to accept.  I'd guess the reason it affects gles2rice more is that it's more CPU intensive than gles2n64 so it's delaying the UI thread even more.  I think the solution is to move most of the work to another thread.  I'm working on this idea now.
did you got it work ???
Title: Re: Alpha Testing Underway!
Post by: Paul on November 13, 2011, 03:55:21 PM
nope
Title: Re: Alpha Testing Underway!
Post by: Paul on November 13, 2011, 05:07:46 PM
Ok, got it working for both video plug-ins.  The whole separate thread idea ended up being way more complicated than I expected due to some things that have to be done on the main UI thread, and synchronizing stuff... fingers crossed that it works on other devices not just my Droid X :o

Resume App Test #2 (http://www.paulscode.com/source/Mupen64Plus-AE/13NOV2011/Mupen64Plus-debug-resume.apk)

As before, provide the logcat output after doing the following test:
1) Run the app and let it load for a bit
2) Press the "Home" button
3) Relaunch from the status-bar
4) Press the "Menu" button and choose "Close"

Be sure to try it for both video plug-ins, and let me know how they behave.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 13, 2011, 05:20:52 PM
xperia play is same as last time  >:(
also i found this:
E/front-end(17735): AttatchCoreLib unsuccessful, returning 2.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 13, 2011, 05:36:21 PM
Every time I try to resume the app via the status bar  it goes back to the emulator but it only shows the controls on a black screen for a second and then kicks me back to the home screen. Its not force closing but it wont allow me to play the game anymore until I shut down the emulator.

Heres the logcat for the default plugin, I have not tried rice yet: http://dl.dropbox.com/u/13594612/paulscode/logcat/alogcat.2011-11-13-23-50-05%2B0000.txt
Title: Re: Alpha Testing Underway!
Post by: Paul on November 13, 2011, 06:04:16 PM
From the logcat, it looks like it is taking a while to shut down, and you are resuming before the shutdown thread has ended.  To test this theory, please repeat the test again and post the logcat, but this time wait about 20 seconds after loading the app before you press home, and then wait 20 seconds before resuming the app from the status-bar icon, then wait 20 seconds before pressing "Close".  If that's the problem, I'll have to add in some more logic for cases where the resume sequence begins before the shutdown sequence has completed.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 13, 2011, 06:17:32 PM
From the logcat, it looks like it is taking a while to shut down, and you are resuming before the shutdown thread has ended.  To test this theory, please repeat the test again and post the logcat, but this time wait about 20 seconds after loading the app before you press home, and then wait 20 seconds before resuming the app from the status-bar icon, then wait 20 seconds before pressing "Close".  If that's the problem, I'll have to add in some more logic for cases where the resume sequence begins before the shutdown sequence has completed.

It works!

Heres the logcat: http://dl.dropbox.com/u/13594612/paulscode/logcat/alogcat.2011-11-14-00-19-17%2B0000.txt
Title: Re: Alpha Testing Underway!
Post by: Paul on November 13, 2011, 06:20:09 PM
Thanks..  I'll post a fixed version in a few minutes (I'll have to think about the best way to communicate between the shut-down and start-up threads without creating a potential for deadlock).
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 13, 2011, 06:21:22 PM
Thanks..  I'll post a fixed version in a few minutes (I'll have to think about the best way to communicate between the shut-down and start-up threads without creating a potential for deadlock).

No probs and good luck with that. :)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 13, 2011, 07:00:57 PM
Turns out I can't communicate with the shutdown thread on resuming, because I loose the handle to it (all static variables are reset on resume).  I thought of another possible solution.  This way will close soon after opening if you exit then quickly resume, but it should be ok if you wait about 2 seconds (if it takes much longer for some of you than a reasonable time a user would be expected to normally wait, let me know and I'll try and think of something else)

Resume App Test #3 (http://www.paulscode.com/source/Mupen64Plus-AE/13NOV2011/Mupen64Plus-debug-resume2.apk)
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 13, 2011, 07:06:54 PM
Turns out I can't communicate with the shutdown thread on resuming, because I loose the handle to it (all static variables are reset on resume).  I thought of another possible solution.  This way will close soon after opening if you exit then quickly resume, but it should be ok if you wait about 2 seconds (if it takes much longer for some of you than a reasonable time a user would be expected to normally wait, let me know and I'll try and think of something else)

Resume App Test #3 (http://www.paulscode.com/source/Mupen64Plus-AE/13NOV2011/Mupen64Plus-debug-resume2.apk)

Seems to work fine for me, takes a few seconds for the game to start back up but still it works. :)

Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 13, 2011, 07:08:31 PM
Cant tell if its the savestate or if its actually resuming. Logcat attatched
Title: Re: Alpha Testing Underway!
Post by: Paul on November 13, 2011, 07:17:03 PM
Cant tell if its the savestate or if its actually resuming. Logcat attatched

Try deleting the file Mupen64PlusAE_LastSession.sav and run test #3 again.  If you can get into Mario64 without it crashing, then before testing the resume stuff, try testing the "Save" and "Load" options to make sure they work.  That will let you know if it's a problem with the savestate or not.

Also note, it takes a few seconds to resume (not nearly as fast at resuming as other emulators I've used).  Let me know if the resuming doesn't work after deleting that file.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 13, 2011, 07:20:06 PM
I ran the emulator, pressed the home button, deleted Mupen64PlusAE_LastSession.sav, resumed and the game restarted. So its definitely using that file rather than a save state.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 13, 2011, 07:22:15 PM
yeah same as epic bubble
Title: Re: Alpha Testing Underway!
Post by: Paul on November 13, 2011, 07:27:31 PM
Ok, great.  I still need to do a little tweaking, because there are some strange cases that can potentially happen with this setup.  I think what I'll do is instead of immediately resuming emulation when the user presses on the status bar icon, I'll bring it to the main menu which will have a "Resume Last Session" option on it.  This will also avoid a potential problem that could happen if the user were to leave the emulator immediately before a core crash (such as right after starting Donkey Kong 64), where the saved session would always crash (rendering the emulator unusable).
Title: Re: Alpha Testing Underway!
Post by: VioletLinked on November 13, 2011, 08:09:37 PM
Paul, just wondering, will there be a future conker fix?


EDIT:
Also, do you think there will be any changes in proformance with Icecream Sandwich (4.0)?
Title: Re: Alpha Testing Underway!
Post by: Mats on November 14, 2011, 12:54:17 AM
no one of this resume tests did work
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 14, 2011, 02:43:45 AM
Resume test #3 works on both plugins with tegra 2 and exynos.

@Mats
how can it work for you ? as i understand, you have even problems to let the regulare app running.
this test is only to fix the resume bug, nothing other.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 14, 2011, 06:31:29 AM
no one of this resume tests did work

The fix to your particular problem is closely linked to the main menu (not included in the last 3 tests yet).  It involves loading and unloading the plug-in .so files when you choose plug-ins.  This bug will be fixed in the next official build.  I was just getting the resume stuff working before I add the main menu (that's next, now that the resume stuff seems to be working).
Title: Re: Alpha Testing Underway!
Post by: koekje on November 14, 2011, 07:02:46 AM
Test 3 works fine :) its takes a couple of seconds to load again.

Btw can you make links clickable on the wap version of the website?
Title: Re: Alpha Testing Underway!
Post by: Paul on November 14, 2011, 07:05:39 AM
Btw can you make links clickable on the wap version of the website?
That's built into SMF, but I can do a little searching to see if someone has written a MOD to do that.  To be honest, I've been considering disabling the WAP version of the website entirely, because it is the version that always appears in a google search, and it seriously sucks.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 14, 2011, 07:35:34 AM
no one of this resume tests did work

The fix to your particular problem is closely linked to the main menu (not included in the last 3 tests yet).  It involves loading and unloading the plug-in .so files when you choose plug-ins.  This bug will be fixed in the next official build.  I was just getting the resume stuff working before I add the main menu (that's next, now that the resume stuff seems to be working).
good  :) i cant wait to the next official build :-D
Title: Re: Alpha Testing Underway!
Post by: koekje on November 14, 2011, 07:38:33 AM
Please dont disable the wap version :p it works fine for me except for the links, its much better for mobile devices :)
Title: Re: Alpha Testing Underway!
Post by: Mats on November 14, 2011, 09:33:45 AM
is someone norwegian here ??
Title: Re: Alpha Testing Underway!
Post by: 2blackbar on November 14, 2011, 12:02:26 PM
I ran resume 2 emu again on my galaxy S and it started from the point i closed it before.
Here is logcat:
http://www.mediafire.com/?11n287nbpt31xjs
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 14, 2011, 12:20:12 PM

I was just getting the resume stuff working before I add the main menu (that's next, now that the resume stuff seems to be working).

Yes, it semms to work in mario, but sometimes not on other games.
Test : Conkers bad fur day, SGS2, rice plugin.
Going to homescreen before the menue screen starts, the resume routine starts at the beginning from the intro. Mostly.
In game, and sometimes on the described scenario, the emulator starts with buttons and a black screen and goes to home again. The muppen symbol on status bar is active.
I must delete the .sav file, start the emulator and can close.

logcat

http://db.tt/qJhJg3yM

Is it possible to make the background of the text in postings a little brighter than the background ? It's hard to recognize where one post ends and an other beginns.
First, I thought, that 2 blackbar's post was a part from Mats post.  ???
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 14, 2011, 01:24:25 PM
Hello, I found this project while looking for an n64 emu compatible with my phone as the marketed ones like n64oid and bit64 aren't compatible. I have no programming experience i'm afraid so probably won't be of much use in that area, however as an avid gamer i'm sure to push this emu to its limits. I have never heard of logcat and have no idea how to use it, but if someone wants to email me (freestonethomas-at-yahoo-dot-com) and explain what to do i would gladly send my logs. I have used the program and have successfully run every game I tried (Oot, SS bros, Mario64, and fzerox) on my Samsung Galaxy Ace. I have only tried the default plugin though..
-edit- just attempted resume and it worked but took almost 20 seconds (no log sorry)
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 14, 2011, 01:43:12 PM
search for alogcat in Android market.
in the app-menue, press clear, run the test, go back and save the logcat output.
you'll find it in the folder called alogcat on your sdcard.
now you can attach the logcat to your post.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 14, 2011, 01:46:41 PM
One thing I will say about this forum theme is that it's hard to see when one post starts and another ends, the little white lines don't help all that much.
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 14, 2011, 02:11:53 PM
search for alogcat in Android market.
in the app-menue, press clear, run the test, go back and save the logcat output.
you'll find it in the folder called alogcat on your sdcard.
now you can attach the logcat to your post.
thank you!
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 14, 2011, 02:32:21 PM
ok what i did was open the emu, ran around a bit on mario 64, hit the home button, waited a few seconds then opened it again. (Samsung Galaxy Ace, Default Plugin)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 14, 2011, 05:16:23 PM
Yes, it semms to work in mario, but sometimes not on other games.
Test : Conkers bad fur day, SGS2, rice plugin.
Going to homescreen before the menue screen starts, the resume routine starts at the beginning from the intro. Mostly.
In game, and sometimes on the described scenario, the emulator starts with buttons and a black screen and goes to home again. The muppen symbol on status bar is active.
I must delete the .sav file, start the emulator and can close.

That logcat indicates two different problems.  The first resume, it got all the way until the core reported that the state had been loaded, then it had a segfault.  The other problem begins after a later resume:
Code: [Select]
I/GLThread( 2371): noticed surfaceView surface lost tid=10
W/EglHelper( 2371): destroySurface()  tid=10
E/Surface ( 2371): surface (identity=4686) is invalid, err=-19 (No such device)
E/Surface ( 2371): surface (identity=4686) is invalid, err=-19 (No such device)
E/Surface ( 2371): surface (identity=4686) is invalid, err=-19 (No such device)
This is really strange - I suppose it could just be a result of the previous crash where the SDL thread continued running after the surface was destroyed.  I'll have to figure out the first problem to see if that solves the other one too.

I think we should begin by ruling out any problems with save/ load state for that particular ROM when using the rice plug-in.  Delete the .sav file and run the emulator.  Then without leaving the app, run a few tests with the "Save" and "Load" buttons to see if they cause the app to crash.


ok what i did was open the emu, ran around a bit on mario 64, hit the home button, waited a few seconds then opened it again. (Samsung Galaxy Ace, Default Plugin)

Did it still take almost 20 seconds to resume during those tests, or was that for a different game?

Also, do you have missing or flickery shadows, carpet, stars, etc. in Mario64 with the default gles2n64 plug-in?  It looks like your hardware wasn't recognized by the profiler, so I should improve the logic so it recognizes your device.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 14, 2011, 06:26:11 PM
Test : Conkers bad fur day, SGS2, rice plugin.
Save and load state for Conkers seem to work fine during the intro story for me.  I get the same behavior you do for resume (where it starts over at the beginning of the intro on resume.  The reason for this is that I put a timeout of 10 seconds for waiting for the emulator to load, before it gives up.  Conkers takes a lot longer than that to load, so this isn't really unexpected.  I could increase the timeout to something like 30 seconds to fix this.  I think this will be less of a problem when gles2rice performance improves, since this seems to be the main thing slowing the emulator down.

I am going to test in-game next to see if there are any issues with the save/ load state, or if the problem is due to something else.

--EDIT-- seems to work the same for me in-game as it does in the intro.  Resume still times out after 10 seconds and the game restarts from the beginning of the intro.  There don't seem to be any issues with save and load state in-game.  I think I'll fix the timeout bug, and see if that fixes your problems.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 14, 2011, 06:50:42 PM
I just tried gles2rice and it runs very badly, its slow and textures are messed up but this is probably to be expected in its early stages.

Do you think the performance will ever be up to par with the default video plugin? Im not sure what video plugin n64oid currently uses but it allows the use of custom textures so it must be either rice or glide.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 14, 2011, 07:02:15 PM
The plug-in's speed was cut in half after adding the alpha test code.  I'm sure there are plenty of optimizations that can be done with the code over time, though, especially if we can get a developer who is experienced with assembly to take a look at the pieces that are high-traffic.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 14, 2011, 07:49:14 PM
Ok, resume seems to work fine for Conkers now.  Anyone else have bugs trying to resume a game (other than it taking a really long time)?

scorpio16v, let me know if this one fixes your problems.  If not, let me see another logcat.

Resume App Test #4 (http://www.paulscode.com/source/Mupen64Plus-AE/14NOV2011/Mupen64Plus-debug-resume.apk)

If it seems to be working now, I'll continue on with the rest of the GUI.  At some point I'll come back to work on this some more.  I'm sure it's possible to just pause the emulator and resume it rather than this complicated method I'm using (I have to figure out how to make the SDL surface visible again after leaving, without having to recreate it from scratch).  It's good enough for now though.
Title: Re: Alpha Testing Underway!
Post by: RyuuseiZero on November 14, 2011, 08:34:44 PM
@Paul
Good Work paul, i have a galaxy ace and i'm test your last build(Reusme app test #4), the beginning of rom(m64) work fine, tomorrow i will test the "resume app..."

wait ;)
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 14, 2011, 11:39:56 PM
yes, resume test #4 works.  :)

save/load from menue works too.
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 15, 2011, 04:14:23 AM
ok what i did was open the emu, ran around a bit on mario 64, hit the home button, waited a few seconds then opened it again. (Samsung Galaxy Ace, Default Plugin)

Quote
Did it still take almost 20 seconds to resume during those tests, or was that for a different game?

Also, do you have missing or flickery shadows, carpet, stars, etc. in Mario64 with the default gles2n64 plug-in?  It looks like your hardware wasn't recognized by the profiler, so I should improve the logic so it recognizes your device.
I have only been logging mario 64. It still takes time but not a big deal, I have not experienced missing textures that stuck out but i'll have to play more than a few seconds on mario 64. The only thing is that one time when i resumed it was just a white screen and after that the crash was permanent, even after rebooting and anything else i could think of it wouldn't run again. I got a log of a crash in case it was helpful then re installed the emu. It works now. (The log is of when i attempted to resume and it crashed)
Title: Re: Alpha Testing Underway!
Post by: neo3 on November 15, 2011, 06:07:30 AM
Mario64 runs ok, but sound so laggy. Why?
This is because the framerate is too low, due to your slow ARM6 device.  Overclocking might help improve this, otherwise you will have to disable the audio.

I installed on my Galaxy Ace and the same thing happens, how to disable the audio?
Title: Re: Alpha Testing Underway!
Post by: RyuuseiZero on November 15, 2011, 06:27:25 AM
Ok, i tested in my device and run fine(but, the sound not work good(low framerate i think in some parts), but the save/load system work fine rs' ^^

@neo3
maybe the emulator no supports "disable sound" now, but you can use your device without audio ._.'
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 15, 2011, 06:58:01 AM
I forget how you disable the audio plug in but I do know that as least for now you need root access to do it. If your phone isn't rooted then currently you cant disable the plugin.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 15, 2011, 08:04:30 AM
unzip the apk and then go to lib delete the audioplugin from both maps :) and then zip it and change .zip to .apk :-D  after downloade zipsigner2 from market and sign the file ;)
Title: Re: Alpha Testing Underway!
Post by: neo3 on November 15, 2011, 08:41:24 AM
I was using the release of date 25/10 on my Galaxy Ace, and keyboard appeared normal, now I installed the latest version (5/11) and the keyboard no longer appears. How do I appear?
Title: Re: Alpha Testing Underway!
Post by: RyuuseiZero on November 15, 2011, 08:52:38 AM
Resume App Test #4

Use this build(page 12) work fine in my galaxy ace and have the keyboard
Title: Re: Alpha Testing Underway!
Post by: neo3 on November 15, 2011, 09:13:09 AM
Resume App Test #4

Use this build(page 12) work fine in my galaxy ace and have the keyboard

Thanks! I had not seen this release.

I had to delete the app-data folder and send it again to display the virtual keyboard.
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 15, 2011, 09:16:38 AM
one thing that i really think is needed is an obvious way to change the size of the onscreen buttons. For my phone, (Screenshot below) the buttons are way too big, mostly the analogue.
A question:
What are these posts meaning by keyboard? do you mean the software qwerty keyboard or the virtual gamepad?
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 15, 2011, 09:23:21 AM
one thing that i really think is needed is an obvious way to change the size of the onscreen buttons. For my phone, (Screenshot below) the buttons are way too big, mostly the analogue.
A question:
What are these posts meaning by keyboard? do you mean the software qwerty keyboard or the virtual gamepad?

If your phone has a search key then you can press that to change the pad layout to a smaller one. If not im sure theres a way in one of the config files.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 15, 2011, 09:36:04 AM
unzip the apk and then go to lib delete the audioplugin from both maps :) and then zip it and change .zip to .apk :-D  after downloade zipsigner2 from market and sign the file ;)

I tried that method and it still didnt create an installable apk. I you manage to do it please posts a build here so people with lower spec devices can try it out. :)
Title: Re: Alpha Testing Underway!
Post by: Mats on November 15, 2011, 09:56:43 AM
navigate to app data and paulcode map and open mupen64plus.cfg and find audioplugin then delete audio plugin location :-D  try it ;-) maybye you get som speed up ;-)  il try it
Title: Re: Alpha Testing Underway!
Post by: RyuuseiZero on November 15, 2011, 10:08:32 AM
Hi everyone, i'm test the "Zelda Ocarina of Time" in the last build of mupen64plus, the game work... but very laggy =/.

My Next Test is Resident Evil 2.

ps: Any think what, i get a more speed ?
Title: Re: Alpha Testing Underway!
Post by: neo3 on November 15, 2011, 10:12:44 AM
one thing that i really think is needed is an obvious way to change the size of the onscreen buttons. For my phone, (Screenshot below) the buttons are way too big, mostly the analogue.
A question:
What are these posts meaning by keyboard? do you mean the software qwerty keyboard or the virtual gamepad?

If your phone has a search key then you can press that to change the pad layout to a smaller one. If not im sure theres a way in one of the config files.

Where in the configuration file?
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 15, 2011, 10:25:17 AM
i have looked through the input config file and cannot find any mention of an option to change the size of the game pad. I also cannot figure out how to disable sound. deleting or changing the name of the sound plugin doesn't help. On the Galaxy Ace there is no search key, and so if this opens more options i and the rest of us with full touch phones are probably stuck.. anyone who knows where the option in the config files is that'd be awesome.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 15, 2011, 10:40:35 AM
i have looked through the input config file and cannot find any mention of an option to change the size of the game pad. I also cannot figure out how to disable sound. deleting or changing the name of the sound plugin doesn't help. On the Galaxy Ace there is no search key, and so if this opens more options i and the rest of us with full touch phones are probably stuck.. anyone who knows where the option in the config files is that'd be awesome.

Paul has posted instructions here a few times on how to disable the audio plugin but ever since the forum has been upgraded lots of the old mupen threads are gone so the instructions are not here anymore.

Also I might have found a way to shrink the touch pads manually for you! got to sdcard/app-data/paulscode.android.mupen64plus/skins/gamepads/ and open a file called gamepad_list.ini

In that file there is a list of all the different gamepad layouts, move the one you want to use to the top of the list.

EDIT: the one you probably want to use is the one called mupen64plus-ae-touch-small
Title: Re: Alpha Testing Underway!
Post by: neo3 on November 15, 2011, 10:58:58 AM
i have looked through the input config file and cannot find any mention of an option to change the size of the game pad. I also cannot figure out how to disable sound. deleting or changing the name of the sound plugin doesn't help. On the Galaxy Ace there is no search key, and so if this opens more options i and the rest of us with full touch phones are probably stuck.. anyone who knows where the option in the config files is that'd be awesome.

Paul has posted instructions here a few times on how to disable the audio plugin but ever since the forum has been upgraded lots of the old mupen threads are gone so the instructions are not here anymore.

Also I might have found a way to shrink the touch pads manually for you! got to sdcard/app-data/paulscode.android.mupen64plus/skins/gamepads/ and open a file called gamepad_list.ini

In that file there is a list of all the different gamepad layouts, move the one you want to use to the top of the list.

EDIT: the one you probably want to use is the one called mupen64plus-ae-touch-small

That's right. For the Galaxy Ace the best gamepad is the Mupen64Plus-AE-Analog-Small.
Title: Re: Alpha Testing Underway!
Post by: RyuuseiZero on November 15, 2011, 11:44:01 AM
RE 2 work, but fully bugged(no playable)
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 15, 2011, 11:50:32 AM
And another blurry cam video from me.  ;D

It shows Conker's Bad Fur Day on my Phone with Rice-Plugin and N64oid on my tablet.
You can see, that both have choppy sound and nearly the same graphic glitches.

http://www.youtube.com/watch?v=BPW_9UlKoIY

( embeded videos are not supported in your site ? )
Title: Re: Alpha Testing Underway!
Post by: RyuuseiZero on November 15, 2011, 12:05:28 PM
/\ you can test re2 in your galaxy s2 ? please and post the results.
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 15, 2011, 12:24:13 PM
Resident Evil 2 didn't run on mupen64plus-ae and N64oid. The game shoots down mupen64plus to homescreen. On N64oid, the emulator stays on black screen. Both after the main menue screen.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 15, 2011, 12:38:17 PM
And another blury cam video from me.  ;D

It shows Conker's Bad Fur Day on my Phone with Rice-Plugin and N64oid on my tablet.
You can see, that both have choppy sound and nearly the same graphic glitches.

http://www.youtube.com/watch?v=BPW_9UlKoIY

( embeded videos are not supported in your site ? )

If yonghz was using a modified version of the rice plugin shouldn't he technically have to release the source for it?
Title: Re: Alpha Testing Underway!
Post by: RyuuseiZero on November 15, 2011, 02:06:16 PM
@scorpio16v

Thank you :D
Title: Re: Alpha Testing Underway!
Post by: Paul on November 15, 2011, 05:37:21 PM
how to disable the audio?
The only way at the moment is if you have root access, to delete the file /data/data/paulscode.android.mupen64plus/lib/libaudio-sdl.so.  In theory, it should also be possible to remove the reference to libaudio-sdl.so in the file [sdcard]/app-data/paulscode.android.mupen64plus/mupen64plus.cfg (but there seems to be a problem with this at the moment).

I was using the release of date 25/10 on my Galaxy Ace, and keyboard appeared normal, now I installed the latest version (5/11) and the keyboard no longer appears. How do I appear?
Oftentimes problems can be solved by deleting the folder [sdcard]/app-data/paulscode.android.mupen64plus/ and letting the app re-download it (there may have been changes between those versions, I don't recall off hand).

one thing that i really think is needed is an obvious way to change the size of the onscreen buttons. For my phone, (Screenshot below) the buttons are way too big, mostly the analogue.
The way to switch layouts is to edit the file [sdcard]/app-data/paulscode.android.mupen64plus/skins/gamepads/gamepad_list.ini, and move the layout you want to use to the top of the list.  I'd recommend Mupen64Plus-AE-Touch-Small for small-screen devices.

Any think what, i get a more speed ?
Some ways to improve performance:
1) Ensure your device's OS is updated
2) Use gles2n64, not gles2rice for the video plug-in
3) Select one of the "touch" gamepad layouts instead of "analog"
4) Disable the audio plug-in
5) Reboot your device immediately before running the emulator
6) Study logcat output for unnecessary processes, and kill them
7) Overclock your device if it is rooted
8) Play around with the overclock settings to find the best balance of speed and stability

deleting or changing the name of the sound plugin doesn't help.
This sounds like a bug.  I'll look into it.

Paul has posted instructions here a few times on how to disable the audio plugin but ever since the forum has been upgraded lots of the old mupen threads are gone so the instructions are not here anymore.
The consensus on the SMF support forums is that the posting bug was an issue with my hosting service (of course.. the software people always blame the hardware people).  If so, then it will probably reappear after this thread grows past a certain size, and I'll be forced to save the archive and delete the thread once again.  I'll look into buying another hosting service at some point (I'm really broke at the moment, though, so it might be a while).  As for the instructions, I could update the initial post, but these procedures are all about to become irrelevant - I expect to have the main components of the GUI in place by the end of the week barring any unforeseen problems.

( embeded videos are not supported in your site ? )
You should be able to use the [flash] tag.  For example:
[flash=400,400]http://www.youtube.com/v/BPW_9UlKoIY[/flash]
Would produce this:
http://www.youtube.com/v/BPW_9UlKoIY

If yonghz was using a modified version of the rice plugin shouldn't he technically have to release the source for it?
He should technically release it regardless of whether it is Rice or if he wrote it entirely himself, according to the GPL (he's distributing it as part of a whole work licensed by the GPL, so it too must be licensed by the GPL).  But yeh, there's plenty of evidence at this point that he is using a port of Rice - he most likely ported it to GLES2 himself.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 15, 2011, 05:49:59 PM
Quote
The consensus on the SMF support forums is that the posting bug was an issue with my hosting service (of course.. the software people always blame the hardware people).  If so, then it will probably reappear after this thread grows past a certain size, and I'll be forced to save the archive and delete the thread once again.  I'll look into buying another hosting service at some point (I'm really broke at the moment, though, so it might be a while).  As for the instructions, I could update the initial post, but these procedures are all about to become irrelevant - I expect to have the main components of the GUI in place by the end of the week barring any unforeseen problems.

I dont know about the other users but having to move threads all the time doesn't really bother me if it saves you the costs of upgrading your hosting service and like you said alot of these instructions wont be necessary soon anyways.

Also I know ive said it before but thanks for making this emulator, Its rare that you get an emulator dev that interacts with their user base as much as you have, Its certainly interesting to see how the emulator has evolved since I first used it.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 15, 2011, 05:55:21 PM
In case anyone is interested in more proof that N64oid is using a port of Rice, that particular graphics glitch in Conkers has been in Rice for a long time.  Screenshot from PC version of Mupen64Plus 1.5 with Rice video plug-in:

(http://www.paulscode.com/images/RicePCVersion.png)

Compared to the Glide plug-in:

(http://www.paulscode.com/images/GlidePCVersion.png)
Title: Re: Alpha Testing Underway!
Post by: shinning.king on November 16, 2011, 01:57:26 AM
Haven't posted a message for quite some time. But I have been watching on this thread.
I recently got the latest version of N64oid, and I have to say I am loving it, simply because it has the best game compatibility. It runs EVEN BETTER than Mupen64Plus on PC (with the rice video plugin).

Here are a few points I noticed where N64oid absolutely runs better:

Of course there's gotta be something I missed. Coincident that yongzh managed to have fixed all these bugs by himself? I don't believe it, because every single one of the above issues could probably take a month or longer to fix.
Title: Re: Alpha Testing Underway!
Post by: crualfoxhound on November 16, 2011, 04:21:59 AM
Good news for emulator fans.

Ive just had my samsung galaxy note.
All emulated games run fullspeed.

Fpse- tekken 3 60fps

N64oid - all heavy graphic games
Killer instincts gold
Conkers bad fur day
Fullspeed.
No frameskip

Even then fps drops
Like on the beginning of ridgeracer 64 have conpletely gone.

My galaxy note is rooted but running stock rom

Catch ya later.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 16, 2011, 04:54:49 AM
Of course there's gotta be something I missed. Coincident that yongzh managed to have fixed all these bugs by himself? I don't believe it, because every single one of the above issues could probably take a month or longer to fix.

As compared to how long it would take to develop a new video plug-in from scratch all by himself, you mean  ;)

Just to clarify, no one here is questioning the fact that Yongzh is a talented developer.  All the more reason to get him on-board the opensource bandwagon!
Title: Re: Alpha Testing Underway!
Post by: neo3 on November 16, 2011, 05:57:27 AM
how to disable the audio?
The only way at the moment is if you have root access, to delete the file /data/data/paulscode.android.mupen64plus/lib/libaudio-sdl.so.  In theory, it should also be possible to remove the reference to libaudio-sdl.so in the file [sdcard]/app-data/paulscode.android.mupen64plus/mupen64plus.cfg (but there seems to be a problem with this at the moment).

For those who do not have root access, you could please post a version of the emulator without the audio plugin to gain more speed on the emulation?

I was using the release of date 25/10 on my Galaxy Ace, and keyboard appeared normal, now I installed the latest version (5/11) and the keyboard no longer appears. How do I appear?
Oftentimes problems can be solved by deleting the folder [sdcard]/app-data/paulscode.android.mupen64plus/ and letting the app re-download it (there may have been changes between those versions, I don't recall off hand).

I had done that before and it worked, but thanks!
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 16, 2011, 07:01:00 AM
Quote
For those who do not have root access, you could please post a version of the emulator without the audio plugin to gain more speed on the emulation?

Theres not really much point in doing that atm, the audio plugin can be disabled via the GUI once its implemented.
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 16, 2011, 12:36:27 PM
I have not been able to get zelda oot to resume properly. I can overcome this by simply saving a state, closing, then loading the state next time i want to play, but i thought i would post it anyway. I know you're no longer working on the resume side but anyway here is the log.. I suppose you can file it away for when you resume work on resume :p

I opened the emu, it crashed, opened it again and this time it worked :D graphics issues included: the background of the pause-screen was the texture for the old-link entrance to the market (which doesn't load in normal game play btw) also link doesn't appear in the screen where you change his sword shield etc. but i know this is a problem on my pc emu too. I then presed the menu button and hit menu to go back to the home screen. upon attempting to resume the emu crashed again..
~note~ i am playing the emu with sound disabled ( i've deleted the plugin and it worked yaaaay more fps :D )
Title: Re: Alpha Testing Underway!
Post by: tgwaste on November 16, 2011, 12:36:49 PM
Of course there's gotta be something I missed. Coincident that yongzh managed to have fixed all these bugs by himself? I don't believe it, because every single one of the above issues could probably take a month or longer to fix.

As compared to how long it would take to develop a new video plug-in from scratch all by himself, you mean  ;)

Just to clarify, no one here is questioning the fact that Yongzh is a talented developer.  All the more reason to get him on-board the opensource bandwagon!

trust me, the only thing that crook is thinking about is how he can eventually rip off your work to make money for himself and how he can sell it to the same people over and over.

he's a shaddy pos and we all know it.
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 16, 2011, 01:13:28 PM
http://www.youtube.com/v/mIEhRlM1a_A

some gameplay on my Lg Optimus One with default Android 2.3, airplane mode and task killer (not autokill mode)
sorry for worst cam ever but it's old.
also: is there a way to get audio with lower quality? it could be a nice thing to have low quality audio to hear the sound with more fps in low end devices.

P.s: if i bind a button to the vol-up or Vol-down buttons, will they also work as volume buttons? i literally need the z button somewhere.

EDIT: to get working vids on the forum, copy all the text after the "v=" and paste it in
Code: [Select]
http://www.youtube.com/v/PASTEHERE
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 16, 2011, 01:26:33 PM
Sorry, but I can see only a white square. That's the same when I tried to embed a video.
Have you post from an Android device or a PC ?
On some forums, this happened, if you insert a YT link from a mobile browser. Don't know why ?
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 16, 2011, 01:52:52 PM
Sorry, but I can see only a white square. That's the same when I tried to embed a video.
Have you post from an Android device or a PC ?
On some forums, this happened, if you insert a YT link from a mobile browser. Don't know why ?

when you copy a link from mobile browser, it's in mobile mode (m.linkhere.com) so you have to use the share button and get the links, by the way i copy pasted the link from the browser, if it works it's because it's the one in share button
Title: Re: Alpha Testing Underway!
Post by: Paul on November 16, 2011, 04:20:46 PM
some gameplay on my Lg Optimus One with default Android 2.3, airplane mode and task killer (not autokill mode)
That's surprisingly good performance for an ARM6 600MHz device without overclocking.  You'll probably be able to obtain full-speed with just a few more optimizations (perhaps with the audio plug-in).

is there a way to get audio with lower quality? it could be a nice thing to have low quality audio to hear the sound with more fps in low end devices.
I can definitely write a lower-quality audio plug-in at some point.  Not sure how much of an improvement you'll be able to get from it, but every little bit counts.

P.s: if i bind a button to the vol-up or Vol-down buttons, will they also work as volume buttons? i literally need the z button somewhere.
This is one of the areas I'm going to spend a little extra time on.  I want the volume buttons to control the volume unless they are mapped to N64 buttons or Mupen64Plus functions.  They should control the volume keys again if the in-game popup-menu is open.  And of course they should control the volume in the other menu screens, except when "button listening" is on while mapping buttons.  Basically several possible states the app could be in, and the volume buttons behave differently in each.

EDIT: to get working vids on the forum, copy all the text after the "v=" and paste it in
Code: [Select]
http://www.youtube.com/v/PASTEHERE
Oh, right.  Sorry I forgot to explain that part.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 16, 2011, 04:58:16 PM
I have not been able to get zelda oot to resume properly. I can overcome this by simply saving a state, closing, then loading the state next time i want to play, but i thought i would post it anyway. I know you're no longer working on the resume side but anyway here is the log.. I suppose you can file it away for when you resume work on resume :p
The logcat output only contained the information from one shut-down of the app, and it looks like everything went ok that time.  When you get a chance, could you grab a logcat output immediately after a crash occurs?  This part is definitely something I will come back to (probably right after I finish with the GUI main components), because something as basic as this really has to work consistently before I post the app on the market (talk about a bad first impression!)

graphics issues included: the background of the pause-screen was the texture for the old-link entrance to the market (which doesn't load in normal game play btw) also link doesn't appear in the screen where you change his sword shield etc. but i know this is a problem on my pc emu too.
This is due to one of the N64 frame-buffer modes not being emulated.  As far as I know, the only plug-in that emulates this mode properly is the Jabo Direct3D plugin (for Project64).  I think it is closed-source, unfortunately (I haven't been able to find the code, anyway).

I then presed the menu button and hit menu to go back to the home screen. upon attempting to resume the emu crashed again..
I'll take a look at save/ load states and resuming from the inventory when that frame-buffer bug is active (that could be the cause of the problem)
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 16, 2011, 05:14:43 PM
Quote
This is one of the areas I'm going to spend a little extra time on.  I want the volume buttons to control the volume unless they are mapped to N64 buttons or Mupen64Plus functions.  They should control the volume keys again if the in-game popup-menu is open.  And of course they should control the volume in the other menu screens, except when "button listening" is on while mapping buttons.  Basically several possible states the app could be in, and the volume buttons behave differently in each.

I think an easy way to get around this would to be able to map the volume keys as buttons (like we can currently) but have a separate tick box option to disable the volume buttons from controlling the audio. Yes its a lazy way of doing it but its easier than trying to determine if the volume key is currently being used an an input method. :P
Title: Re: Alpha Testing Underway!
Post by: Paul on November 16, 2011, 05:17:09 PM
I think an easy way to get around this would to be able to map the volume keys as buttons (like we can currently) but have a separate tick box option to disable the volume buttons from controlling the audio. Yes its a lazy way of doing it but its easier than trying to determine if the volume key is currently being used an an input method. :P
I like that - a good temporary fix to get things rolling until I come back and start adding more detail to the GUI menus.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 16, 2011, 06:11:48 PM
I did a quick mock-up of what it would look like because im bored haha.

(http://i.imgur.com/FOgqq.png)
Title: Re: Alpha Testing Underway!
Post by: VioletLinked on November 17, 2011, 01:15:32 AM
Good news for emulator fans.

Ive just had my samsung galaxy note.
All emulated games run fullspeed.

Fpse- tekken 3 60fps

N64oid - all heavy graphic games
Killer instincts gold
Conkers bad fur day
Fullspeed.
No frameskip

Even then fps drops
Like on the beginning of ridgeracer 64 have conpletely gone.

My galaxy note is rooted but running stock rom

Catch ya later.

Conker should still slow down in some parts, right? (It has been found that there are significant frame rate drops in-game) It did on the actual Nintendo 64.
Title: Re: Alpha Testing Underway!
Post by: VioletLinked on November 17, 2011, 01:21:00 AM
I just tried gles2rice and it runs very badly, its slow and textures are messed up but this is probably to be expected in its early stages.

Do you think the performance will ever be up to par with the default video plugin? Im not sure what video plugin n64oid currently uses but it allows the use of custom textures so it must be either rice or glide.

It uses 2 diffrent video plugins. Yongzh made both I belive, dont quote me on that though. the user can choose in options. There is Fog support in both video plugins.

(Edited for clarification)
Title: Re: Alpha Testing Underway!
Post by: VioletLinked on November 17, 2011, 01:31:14 AM
Hey I found this:

http://www.youtube.com/v/dlGvL4dQ-4w

I know its not the Samsung Galaxy Note, but the specs are similar.
CrualFoxHound wasn't kidding. Some sound hicups though. lol.
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 17, 2011, 03:15:50 AM
hmm, there's the n64 controller in the bind file, how can i connectbmy N64 controllers to my smartphone...
P.S: wow seeing that much sm64 videos made me want to connect my n64 ;)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 17, 2011, 04:54:30 AM
It uses 2 diffrent video plugins. Yongzh made both I belive, dont quote me on that though. the user can choose in options. There is Fog support in both video plugins.

(Edited for clarification)
Lachlan wrote gles2n64 (ported from GLN64, originally by Orkin).  Yongzh modified it to run on Android and fixed a few of the bugs.  As for the other plugin, Yongzh either wrote it entirely from scratch (unlikely IMO, but not impossible) or ported an existing plug-in to GLES2 (most likely Rice).
Title: Re: Alpha Testing Underway!
Post by: Paul on November 17, 2011, 05:01:15 AM
hmm, there's the n64 controller in the bind file, how can i connectbmy N64 controllers to my smartphone...
If your device is rooted, I believe you can compile the missing linux USB toolchains and drivers, and buy a N64 to USB converter and USB to micro-USB converter.  It would be a huge project, but theoretically possible.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 17, 2011, 05:46:53 AM
hmm, there's the n64 controller in the bind file, how can i connectbmy N64 controllers to my smartphone...
If your device is rooted, I believe you can compile the missing linux USB toolchains and drivers, and buy a N64 to USB converter and USB to micro-USB converter.  It would be a huge project, but theoretically possible.

ICS (android 4.0) will have support for HID devices so a with a n64 to usb converter it could just work without having to compile any third party drivers. If this is true then the best thing to do would be to upgrade the phone with a custom rom if the phone carrier doesn't already issue the update for that particular phone. But again this is a maybe, theres no guarantee an n64 to usb converter will just work out of the box with ICS like normal HID controllers but its a possibility.
Title: Re: Alpha Testing Underway!
Post by: crazyxelite on November 17, 2011, 07:27:45 AM
Cyanogen support hid devices...hey paul i have a mini bluetooh keyboard will work when gui completed? Thanks
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 17, 2011, 09:53:19 AM
hmm, there's the n64 controller in the bind file, how can i connectbmy N64 controllers to my smartphone...
If your device is rooted, I believe you can compile the missing linux USB toolchains and drivers, and buy a N64 to USB converter and USB to micro-USB converter.  It would be a huge project, but theoretically possible.
my optimus one isn't rooted, can't this work with the sdl scancode? i want a n64 to micro usb cable, NOW
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 17, 2011, 12:17:48 PM
hmm, there's the n64 controller in the bind file, how can i connectbmy N64 controllers to my smartphone...
If your device is rooted, I believe you can compile the missing linux USB toolchains and drivers, and buy a N64 to USB converter and USB to micro-USB converter.  It would be a huge project, but theoretically possible.
my optimus one isn't rooted, can't this work with the sdl scancode? i want a n64 to micro usb cable, NOW

Its not really an issue with the emulator recognising scancodes its more of an issue of getting the n64 controller to be useable with an android phone, even with the usb converter you still need to correct drivers for the device to actually pick it up and make it useable.

EDIT: I know its not as good as using a real n64 controller but there are ways to use wiimotes and PS3 controller with android so I could tell you how to use them if you wanted.
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 17, 2011, 12:37:47 PM
N64oid supports USB gamepads on tablets. I have tested it with an sixaxis. Left analog Stick works perfect for precise direction input. So in theory, it should work on mupen64plus-ae if I edit InputAutoCfg.ini ?
If yes, has anyone a working config for a PS 3 Sixaxis controller ?
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 17, 2011, 12:49:01 PM
N64oid supports USB gamepads on tablets. I have tested it with an sixaxis. Left analog Stick works perfect for precise direction input. So in theory, it should work on mupen64plus-ae if I edit InputAutoCfg.ini ?
If yes, has anyone a working config for a PS 3 Sixaxis controller ?

Ah yes I forgot honeycomb has HID support too so yes it should work, use the scancode app to get the scancodes and put them in the InputAutoCfg file.

If you cant get it to work I could make the config file for you.
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 17, 2011, 12:55:13 PM
No, digital keymapping isn't the problem for me.  ;D
But the SDL scancode finder recognized the left analog stick only as digital input (same scancodes). The right one isn't recognized.

My goal is to make the left analog stick work, like it works on N64oid.
In the config are several gamepads with analog input, but I don't know how it could be done for my sixaxis.

edit:  here is a logcatt that shows how the sixaxis is recognized from my tab

http://db.tt/d8d5vvZr
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 17, 2011, 01:06:25 PM
No, digital keymapping isn't the problem for me.  ;D
My goal is to make the left analog stick work, like it works on N64oid.
In the config are several gamepads with analog input, but I don't know how it could be done for my sixaxis.

Are you using this app to pair the sixaxis? https://market.android.com/details?id=com.dancingpixelstudios.sixaxiscontroller&hl=en That app doesnt support analog control only digital even on the analog stick (thats what the description says anyway).

If you have the ps3 controller plugged into your tablet by usb and are doing it that way then I have no idea how to use proper analog input with Mupen sorry.


EDIT: silly me yes your doing it by USB haha. I think analog support would have to be built into the emulator. Have you tried your sixaxis with FPSE?
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 17, 2011, 01:20:40 PM
Yes, I try the USB way.
BT isn't the problem. I have the sixaxis tool, bluezIME and even bought the GamePro driver for my BT gamepads.
To set mouse input works too on mupen64plus-ae. So in theory, analog input on USB should be possible ?

I use my sixaxis, because I have no other USB gamepad and even no PS 3.  ;D
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 17, 2011, 01:37:04 PM
Quote from: Epic_bubble

Its not really an issue with the emulator recognising scancodes its more of an issue of getting the n64 controller to be useable with an android phone, even with the usb converter you still need to correct drivers for the device to actually pick it up and make it useable.

EDIT: I know its not as good as using a real n64 controller but there are ways to use wiimotes and PS3 controller with android so I could tell you how to use them if you wanted.
nah already know how to use wiimotes, someone should actually do the classic controller/n64 controller with a micro usb ending, even a different controller, no one did this so far
Title: Re: Alpha Testing Underway!
Post by: Mats on November 17, 2011, 01:52:31 PM
Quote from: Epic_bubble

Its not really an issue with the emulator recognising scancodes its more of an issue of getting the n64 controller to be useable with an android phone, even with the usb converter you still need to correct drivers for the device to actually pick it up and make it useable.

EDIT: I know its not as good as using a real n64 controller but there are ways to use wiimotes and PS3 controller with android so I could tell you how to use them if you wanted.
nah already know how to use wiimotes, someone should actually do the classic controller/n64 controller with a micro usb ending, even a different controller, no one did this so far
Maybe because more people have wii controller and ps3 controllers
Title: Re: Alpha Testing Underway!
Post by: Paul on November 17, 2011, 04:10:20 PM
someone should actually do the classic controller/n64 controller with a micro usb ending, even a different controller, no one did this so far
The hardware would be quite simple.  You'd just need the following two adapters:

N64 to USB (http://www.ebay.com/itm/N64-Controller-Adapter-PC-USB-Converter-NEW-/250858121851?pt=Video_Games_Accessories&hash=item3a684f2a7b)

USB to Micro USB (http://www.ebay.com/itm/High-Quality-micro-USB-USB-Female-Cable-USB-OTG-N900-/150697510944?pt=PDA_Accessories&hash=item2316458820)

I've used that first adapter with Mupen64Plus on my PC for years.  In Linux, it is detected as one of the default generic joysticks, and it doesn't require any special drivers.  In theory, if the same components were included on some recent version of Android, then it would work out-of-the-box.. otherwise you'd have to compile the missing components for ARM, and install them on your phone (requiring root privileges, of course).  Hell, just out of curiosity, I might try this with my phone at some point..

--EDIT--
I found an interesting article (http://www.tombom.co.uk/blog/?p=124) on how create a simple USB dongle for enabling the MicroUSB port as a host interface (apparently it doesn't switch automatically, even though it is supposed to be USB-OTG).  The article was written with the Motorola Droid in mind, but I expect the process would be similar for other devices.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 17, 2011, 04:15:50 PM
Cyanogen support hid devices...hey paul i have a mini bluetooh keyboard will work when gui completed? Thanks
It should work now using the scancode finder.. but yeh there's no reason it wouldn't work with the GUI button detection code as well.

Yes, I try the USB way.
BT isn't the problem. I have the sixaxis tool, bluezIME and even bought the GamePro driver for my BT gamepads.
To set mouse input works too on mupen64plus-ae. So in theory, analog input on USB should be possible ?

I use my sixaxis, because I have no other USB gamepad and even no PS 3.  ;D
It should work just fine with Mupen64Plus AE, as long as the OS detects it as a joystick and not a keyboard or unknown device (the profile for sixaxis should be in the config file - lots of people use them).  If it's having problems, the bug may be related to that message about discarding the joystick because it has to many axis.  Could you provide a logcat running Mupen64Plus AE with the sixaxis physically connected to your device?

--EDIT--
Yes, it has a profile in AutoInputCfg.ini already, so it aught to work:
Code: [Select]
[Sony PLAYSTATION(R)3 Controller]
[OSX: PLAYSTATION(R)3 Controller]
plugged = True
plugin = 2
mouse = False
AnalogDeadzone = 4096,4096
AnalogPeak = 32768,32768
DPad R = button(5)
DPad L = button(7)
DPad D = button(6)
DPad U = button(4)
Start = button(3)
Z Trig = button(8)
B Button = button(15)
A Button = button(14)
C Button R = axis(2+)
C Button L = axis(2-)
C Button D = axis(3+)
C Button U = axis(3-)
R Trig = button(11)
L Trig = button(10)
Mempak switch =
Rumblepak switch =
X Axis = axis(0-,0+)
Y Axis = axis(1-,1+)
If not, hopefully there is something helpful in the logcat output.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 17, 2011, 04:51:35 PM
I just noticed that since I upgraded the forum to SMF 2.0, Google has finally started listing this thread with the default theme rather than the ugly WAP2 theme.  I used to be up around first or second place for most relevant searches, but got knocked down after deleting the archives..  Hopefully I'll continue to rise back up to the top  ;D
Title: Re: Alpha Testing Underway!
Post by: RyuuseiZero on November 17, 2011, 06:32:04 PM
Quote
Some ways to improve performance:
1) Ensure your device's OS is updated
2) Use gles2n64, not gles2rice for the video plug-in
3) Select one of the "touch" gamepad layouts instead of "analog"
4) Disable the audio plug-in
5) Reboot your device immediately before running the emulator
6) Study logcat output for unnecessary processes, and kill them
7) Overclock your device if it is rooted
8) Play around with the overclock settings to find the best balance of speed and stability

Thank You Pauls, but, overclock my device ? I bought not long ago, my device is galaxy ace(800mhz), OC is possible to do it? if so, have any idea how far without damaging?

Sorry My Bad English x-x''

Title: Re: Alpha Testing Underway!
Post by: Paul on November 17, 2011, 06:51:32 PM
my device is galaxy ace(800mhz), OC is possible to do it?
One way would be to install cyanogen mod, because it has an overclock tool built into it (this post (http://blog.nishant.me/tag/how-to-install-cyanogen-mod-on-galaxy-ace/) talks about it, but it isn't very detailed)  You should do some research with Google to see what other Galaxy Ace users recommend.

if so, have any idea how far without damaging?
I don't know - you should research before you start.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 17, 2011, 06:58:10 PM
Quote
Some ways to improve performance:
1) Ensure your device's OS is updated
2) Use gles2n64, not gles2rice for the video plug-in
3) Select one of the "touch" gamepad layouts instead of "analog"
4) Disable the audio plug-in
5) Reboot your device immediately before running the emulator
6) Study logcat output for unnecessary processes, and kill them
7) Overclock your device if it is rooted
8) Play around with the overclock settings to find the best balance of speed and stability

Thank You Pauls, but, overclock my device ? I bought not long ago, my device is galaxy ace(800mhz), OC is possible to do it? if so, have any idea how far without damaging?

Sorry My Bad English x-x''

Research on other forums, see what other users with the same phone as you think what is the most your should overclock.

Usually overclocking by 100 or 200 mhz doesnt hurt but it greatly varies on the device your using.
Title: Re: Alpha Testing Underway!
Post by: RyuuseiZero on November 17, 2011, 07:08:05 PM
Thank Pauls and Epic_bublle i research on other forums XD wait.

if the oc not sure e_e ''

(http://hypermundo.com.br/wp-content/uploads/2009/08/iphone-pegou-fogo-2.jpg)

OMG...

and sorry my bad english?
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 18, 2011, 12:28:35 AM
wow i just found out my optimus one is 800mhz but LG blocked it at 600mhz because of heating problems, when i want i could freely overclock my smartphone to 700mhz without caring if the device would break :D
Title: Re: Alpha Testing Underway!
Post by: koekje on November 18, 2011, 03:49:19 AM
I dont think you bhave to worry that much about overclocking, my phone is 800mhz and i have it overclocked at 1400 and no overheating or anything.
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 18, 2011, 08:26:17 AM
Could you provide a logcat running Mupen64Plus AE with the sixaxis physically connected to your device?

yes, here. But it semms, that the emulator didn't recognized it.

http://db.tt/LVN0pXvs

As I understand my first logcat, it loads the pad as a keybord and I can only map the buttons and the left stick has the same keycodes as the D-pad.
Maybe yongzh used  the same solution as for the nubbs on iControlpad for analoginput ?

edit:
on terminal dmesg shows

Code: [Select]
6>[75165.898682] avp_lib: Successfully unloaded 'nvmm_h264dec.axf'
<6>[75165.938626] avp_lib: Successfully unloaded 'nvmm_service.axf'
<6>[75165.969590] avp_lib: Successfully unloaded 'nvmm_manager.axf'
<6>[75169.033028] Speaker Disable !
<6>[75402.038794] usb 1-1: new full speed USB device using tegra-ehci and address 9
<6>[75402.242815] usb 1-1: New USB device found, idVendor=054c, idProduct=0268
<6>[75402.243022] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
<6>[75402.243356] usb 1-1: Product: PLAYSTATION(R)3 Controller
<6>[75402.243553] usb 1-1: Manufacturer: Sony
<6>[75402.336317] input: Sony PLAYSTATION(R)3 Controller as /devices/platform/tegra-ehci.2/usb1/1-1/1-1:1.0/input/input12
<6>[75402.337104] sony 0003:054C:0268.0008: input: USB HID v1.11 Joystick [Sony PLAYSTATION(R)3 Controller] on usb-tegra-ehci.2-1/input0
<3>[75734.835290] init: untracked pid 8377 exited
<3>[75735.069160] init: untracked pid 8394 exited
sh-3.2$

and ' cat /dev/input/js0 ' shows an reaction of all buttons and sticks, even analog output on L2/R2 shoulderbuttons

But to make something workable with my findings goes way over my mind.  :-\

ok, I've made ' chmod 777 /dev/input/js0 ' and installed gamepad IME from market and got a logcat output with anlog output. But even after setting the keyboard to 'False' in the .ini, the emulator didn't recognized the sixaxis.

http://db.tt/LbYwJ9TR

If you're interested in this IME, here is the website of the developer. You can even find the source code on this site.

http://sven.killig.de/android/GamepadIME/
Title: Re: Alpha Testing Underway!
Post by: xyz`1 on November 18, 2011, 10:20:03 AM
How do i get it to frameskip? spiderman gets laggy so i need to frameskip and how do i save? i know its alpha but please answer.. great work though n64oid force closed on me..just solve those 2 problems and i shall be indebted to you forever!
Title: Re: Alpha Testing Underway!
Post by: xyz`1 on November 18, 2011, 10:23:25 AM
device-zte blade overclocked to 729 mhz 512mb ram adreno 200 gpu
Title: Re: Alpha Testing Underway!
Post by: maloi17s on November 18, 2011, 12:24:01 PM
Hey Paul i can't disable the audio plugin on my galaxy ace.Could you help me with that?And is there any way to make on-scren interface a bit smaller?
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 18, 2011, 12:53:37 PM
Hey Paul i can't disable the audio plugin on my galaxy ace.Could you help me with that?And is there any way to make on-scren interface a bit smaller?
hint one: read back a few pages in the forum :P however i am nice ;)
To disable plugin you can do one of two things:
wait until ui is finished
or root your device and go to the directory dada/data/paulscode.android.mupen64plus/lib and delete the sound plugin (libaudio-sdl.so)

to change the game pad you would normally hit the search key, however that key doesn't exist on the ace :( so you have to go to /sdcard/app-data/paulscode.andrd.m64+/skins/gamepads
look for the file gamepad_lists.ini and move the one you want to the top of the list. I have the same phone as you and my favorite is the 'small analogue' but paul says that the 'touch' options are faster eg. less lag (although it cant be significant)
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 18, 2011, 01:05:05 PM
sorry to double post but i decided i wanted to ask a question. I have the stock android 2.3.3 rom (root) and i experience minor lag on mario 64 but more on other games. I noticed that paul or someone said to make sure we had the latest rom for our device (2.3.4 for me) and i was wondering if anyone who also has the galaxy ace could tell me if they have less lag after upgrading and anything else you did to increase speed. I plan on overclocking after a custom rom is released for the galaxy ace. I think villainrom is in version 1.0 for the ace.. i'd rather wait for it to have some more bugs ironed out.
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 18, 2011, 02:07:47 PM
I dont think you bhave to worry that much about overclocking, my phone is 800mhz and i have it overclocked at 1400 and no overheating or anything.

yes but then they made the optimus hub aka  an upgraded optimus one with a better quality processor and it's 800mhz, in fact the hub is O1's successor, when the smartphone gets old i might overclock it to 700mhz, people say it's the best option.
also your smartphone's an htc, htcs always have awesome hardware so even if you overclock to 2mhz it could still work
Title: Re: Alpha Testing Underway!
Post by: Paul on November 18, 2011, 04:37:27 PM
and ' cat /dev/input/js0 ' shows an reaction of all buttons and sticks, even analog output on L2/R2 shoulderbuttons
Strange.  I thought /dev/input/js0 was how SDL interfaces with the joystick in the first place.  There may be a deficiency in the Android port of SDL that is causing this (I'll ask on the support forum if anyone has experience with joysticks on Android).  Once I can verify that the Android port of SDL can actually handle joysticks, I'll start putting in debug messages to try and track down the problem.

As I understand my first logcat, it loads the pad as a keybord and I can only map the buttons and the left stick has the same keycodes as the D-pad.
Maybe yongzh used  the same solution as for the nubbs on iControlpad for analoginput ?
His solution must be completely different than the way vanilla Mupen64Plus operates, because he's project is not using SDL at all.  There are a lot of ways to "skin a cat", as they say, so I'm confident if I can't do it through SDL, there will be another way to get the input (this is Linux, after all - there is a ton of source code related to joysticks out there).

How do i get it to frameskip? spiderman gets laggy so i need to frameskip and how do i save? i know its alpha but please answer.. great work though n64oid force closed on me..just solve those 2 problems and i shall be indebted to you forever!
From what I've gathered, this function was handled differently in different versions of gles2n64.  I haven't looked that closely at this part of the code for the version I'm using to know how to configure it (it would be done through the config file).  This is one of the areas I will focus on after finishing the GUI.  I need to get my hands on the source code for a couple builds of gles2n64 from the Pandora project for comparison, and figure out which version works best for most folks.

my favorite is the 'small analogue' but paul says that the 'touch' options are faster eg. less lag (although it cant be significant)
The lag is not significant, but on lower-end devices or higher-end games every little bit counts.  I've had a couple people tell me that the lag was very noticeable to them.  I can't tell any difference on my phone, though.
Title: Re: Alpha Testing Underway!
Post by: xyz`1 on November 19, 2011, 05:30:48 AM
Through the configuration file how? Can I do it?
Title: Re: Alpha Testing Underway!
Post by: RyuuseiZero on November 19, 2011, 07:20:18 AM
@TFreestone
I have in my device the android 2.3.4, is this ?

If yes, i play mario64 good ._.'
Title: Re: Alpha Testing Underway!
Post by: Paul on November 19, 2011, 08:09:54 AM
Through the configuration file how? Can I do it?
It is handled differently in different versions of the plug-in.  I haven't looked that closely at this part of the code to know how or even if it is supported in the version I'm using.
Title: Re: Alpha Testing Underway!
Post by: neo3 on November 19, 2011, 09:19:47 AM
sorry to double post but i decided i wanted to ask a question. I have the stock android 2.3.3 rom (root) and i experience minor lag on mario 64 but more on other games. I noticed that paul or someone said to make sure we had the latest rom for our device (2.3.4 for me) and i was wondering if anyone who also has the galaxy ace could tell me if they have less lag after upgrading and anything else you did to increase speed. I plan on overclocking after a custom rom is released for the galaxy ace. I think villainrom is in version 1.0 for the ace.. i'd rather wait for it to have some more bugs ironed out.

My Galaxy Ace is with the original rom 2.3.4 without root, and the Mario 64 runs fine, but the sound has a little lag.

I tested other games as: Mario Party 2, The Legend of Zelda and Mario Tennis, but has much lag because of the sound.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 19, 2011, 02:14:45 PM
how it goes with the GUI ?
Title: Re: Alpha Testing Underway!
Post by: Paul on November 19, 2011, 02:50:31 PM
how it goes with the GUI ?

It is going well.  Everything is working so far (other than the core restart function, but I'll worry about that bug later).  It's in several pieces at the moment - I'll try and get it all put together this weekend.  I need to come up with some better logic for controlling which views are visible (the code is pretty hackish at the moment)
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 19, 2011, 04:15:40 PM
sounds good  ;D
and i rooted my xperia play  8)
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 19, 2011, 06:01:39 PM
sounds very good indeed :) can't wait! thanks for all your hard work!
Title: Re: Alpha Testing Underway!
Post by: Mats on November 19, 2011, 06:39:11 PM
some new test coming this week ??
Title: Re: Alpha Testing Underway!
Post by: Mats on November 19, 2011, 06:40:15 PM
some new tests'???
Title: Re: Alpha Testing Underway!
Post by: Paul on November 19, 2011, 06:58:46 PM
Soon.  Once I get everything together, I'm sure we'll have to work out a few ANR issues on some of the more sensitive devices (seems to be the most reoccurring issue I've been dealing with since the project started).  I'll try to have everything ready to test some time tomorrow, if nothing comes up.

This is the last piece I'll be debugging this round of tests.  There are still plenty of bugs, but I feel like I've surpassed my original goals for the alpha testing phase.  It's exciting to finally be nearing the beta testing phase - I expect things will really start hopping once a wider audience discovers the project.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 20, 2011, 03:32:56 AM
nice thanks for your hard work  ;P
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 20, 2011, 04:10:03 AM
just a note my hardware is still not being recognized. The emulator is very stable now but I experience a crash every time I boot up the application for the first time after i turn the phone on again after shutting down for the night or doing a reboot for other reasons. Nothing i have done has made this crash go away. Its not a fatal crash especially since all i have to do is let it crash then open the app again and it works fine. I'll collect a couple of alogcat readouts with miscellaneous bugs including that crash and the several graphics glitches i experience on the more high end games, such as the textures failing to load in Links house, several houses in kakariko village, the entrances to the temple of time and the castle market, and finally the failure to resume properly often times. On Smash Bros the percentage and character symbols texture fails to appear except for a few seconds here and there (usually after someone has been hit far off the stage causing the camera to zoom out), also on the game mode selection screen and she score screen after each level of classic mode the screen is glitched to a large degree.
I also experience a general emulator glitch (one that i think others have shared as well), when loading a game sometimes it uses the resume save instead of the rom save. eg. when i don't want it to it resumes the game.

Games in which i have experienced no noticeable glitches: F-Zero X and Mario 64 (still need to test others)

~alogcat Descriptions~
"Zelda Resume from start" : Usually when starting a rom in the emu it boots the rom save, and in the case of zelda you can then choose from 3 saved games and begin from either the temple of time as an adult or links house as a child, if you are inside a dungeon you start at the entrance to said dungeon. A glitch that i an several others have experienced is that the emu loads the resume save every time instead of only when resuming.
"Mu64 fail at startup" : the first time i boot up the emu after booting up the phone it crashes
"Smash bros" Just a log of smash bros game play. basicly a log of the glitches that i described above.
"Zelda glitches" a log of me running around looking for all the graphical glithes i could think of off the top of my head. (Temple of time entrance etc texture fail, and the start screen background glitch) all of these are shown in my gameplay video which has it's own accompanying log.
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 20, 2011, 06:15:42 AM
Can't wait for the GUI, what settings are you planning to add to the first release of the GUI?
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 20, 2011, 07:31:30 AM
~continuation of earlier post~
Gameplay Video
http://www.youtube.com/v/SoqpClNlrj0
~notes~
As you can see there is an unholy amount of lag
The captions should point out the things I wanted to show
I have decided that the missing textures are all from places that use a still 2d image as their texture, rather than to create a 3D environment.
The part i cut out is just the 30 seconds that it took link to die so that i could get out of the boss battle
The accompanying log might be useful or not.. sorry it's so long :P
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 20, 2011, 09:12:29 AM
~continuation of earlier post~
Gameplay Video
http://www.youtube.com/v/SoqpClNlrj0
~notes~
As you can see there is an unholy amount of lag
The captions should point out the things I wanted to show
I have decided that the missing textures are all from places that use a still 2d image as their texture, rather than to create a 3D environment.
The part i cut out is just the 30 seconds that it took link to die so that i could get out of the boss battle
The accompanying log might be useful or not.. sorry it's so long :P

Did you have your phone on mute or was the audio plugin disabled? Disabling the audio plugin will give you a small speed boost. Also your phones clock speed is a little too low for n64 emulation, it risks damaging your phone but you could overclock to improve speeds.

Also the n64 Zelda games are some of the slower n64 games to emulate, even on my xperia play I get alot of slowdown but games like mario 64 run buttery smooth.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 20, 2011, 09:27:02 AM
Thanks for the thorough testing and documentation, TFreestone.  Could you do some similar testing with the gles2rice video plug-in for the games you've noticed graphics problems?  It will run slow as hell, but I'm curious if some of the issues you mentioned are fixed (gles2n64 has a lot of problems).

The cause of your initial startup crash seems to be that the app is checking the emulator state too soon (not sure why it only happens one time - to be honest, I don't know why it is even working for anyone now that I think about it)  I'll have to think of a better way to do this.

The startup behavior in your video is normal for the version of the app you are running.. it's one of the resume tests, so naturally it resumes when you start it ;).  In the upcoming official build, "Resume" is one of the options in the main menu (vs. "Open ROM", which starts a game from the beginning).  Resume will take a long time until I figure out how to do it without having to recreate the SDL surface (something I'll work on again soon).

Most of the Zelda graphics glitches you demonstrated (wrong/missing background textures and missing image of Link) are related to a well known and documented deficiency in current N64 emulation.  They are due to the fact that one of the N64 framebuffer modes is not emulated properly.  The problem is specific to static 2D background textures.  As you mentioned in your comments, this issue affects every N64 emulator out there.  It is improved to various degrees in various plug-ins (some of the areas in-game are textured correctly with some video plug-ins, for example), but I know of only one video plug-in which emulates this framebuffer mode correctly (and unfortunately it is closed-source, so someone will have to re-invent the wheel to solve the issue definitively).

what settings are you planning to add to the first release of the GUI?
Running the app or clicking the status-bar icon brings you to the Main menu.
Main menu has Open ROM, Resume, Plug-ins, Skins, and Close.
    Open ROM brings up a basic file browser.  Clicking a ROM file selects it and starts the emulator.
    Resume resumes the last session (needs work.. it should remember which ROM was opened last).
    Plug-ins menu has Video, Audio, Input, RSP, and Core.
        These menus have Change, Configure, and Enabled.
            Change brings up a file browser (needs work.. goes to sdcard instead of /data/data/..etc).
            Configure only works for Input and Core.
                Configure Input has A button, B button, etc. and Disable volume buttons.
                Configure Core has Reset, Pause, Fast Forward, etc. and Disable volume buttons.
            Enabled (checkbox to enable/ disable the plug-in).
    Skins just has Virtual Gamepad at the moment.
        Virtual Gamepad has Select Layout, Display FPS, and Enabled.
            Select Layout lists the layouts to choose from (needs work.. should be possible to import new layouts).
            Display FPS (checkbox to enable/ disable the FPS indicator).
            Enabled (checkbox to enable/ disable the on-screen gamepad).
    Close Closes the app.
In-game menu has Menu, Restart, Save, Load, and Close.
    Menu saves the session and brings you back to the Main menu.
    Restart restarts the emulator (currently broken).
    Save does a save-state.
    Load does a load-state.
    Close saves the session and closes the app.
Home Button saves the session and returns to the home screen.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 20, 2011, 10:56:29 AM
Might i suggest renaming the plugins section just to settings so really non developer users dont get confused?
Title: Re: Alpha Testing Underway!
Post by: Mats on November 20, 2011, 11:03:51 AM
is some of the futures added, if it post a test ;D
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 20, 2011, 11:17:27 AM
Might i suggest renaming the plugins section just to settings so really non developer users dont get confused?
if they don't even know what a plugin is...
@epic_bubble
I have dissabled the sound
i know all that
also why eould paul build in support for armv5-7 if he didn't want people with slower phones to use it?
i will overclock once villainrom is done for the galaxy ace.
Thanks for sharing though
@paul
i will :) any preference of game or just all of em?
Title: Re: Alpha Testing Underway!
Post by: vicsiol on November 20, 2011, 11:17:44 AM
Great work paul
First emulator for armv6
My galaxy 5 say thanks
:D
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 20, 2011, 11:42:55 AM
Might i suggest renaming the plugins section just to settings so really non developer users dont get confused?

I kind of agree with this, people with a little emulator knowledge will know what a plugin is but average users might be a little confused.
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 20, 2011, 11:45:56 AM
@paul
i will :) any preference of game or just all of em?
I belive, if you'll test zelda or other heavy titles, you'll need much time for the slomo-dia-show.  ;D
zelda is even very slow on dual cores with rice plugin.

Funny thing is, that titles like diddi kong racing run better and faster on rice than on gles2n64 for my SGS2 and choppy and slow on tegra2  devices.  :o
Title: Re: Alpha Testing Underway!
Post by: Mats on November 20, 2011, 11:47:07 AM
this is a great emulator and my loved xperia x8 say thanks  ;)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 20, 2011, 12:14:10 PM
Might i suggest renaming the plugins section just to settings so really non developer users dont get confused?
I suppose that makes sense in the current basic setup.  Eventually, though, the GUI is going to be focused around the skins and plug-ins, so I reserve the right to change it back in the future when it makes more sense ;D

is some of the futures added, if it post a test ;D
I'll post a test soon.  Just trying to bring all the pieces together (keeping track of the views is a bit more complicated than it seems at first glance).  There are a few minor bugs that I mentioned as well that I want to address first (so the tests can focus on compatibility issues rather than fixing bugs I already know about).  They called me in to work this afternoon, so I probably won't have this finished today like I planned.

why eould paul build in support for armv5-7 if he didn't want people with slower phones to use it?
The main reason for this is because "necessity is the mother of invention", as they say.  I figure folks with slower devices will be the driving force behind optimizations and getting the emulator to run as efficiently as possible.  There's really no reason 1 GHz or higher is necessary to emulate a 93.75 MHz chip.  The general rule-of-thumb minimum requirement for emulating a CPU is at least 5X speed on the host hardware, which would translate to 470 MHz.  Clearly there is plenty of room for improvement.

i will :) any preference of game or just all of em?
Any that you had strange graphics problems (this is more out of curiosity than anything)  I expect gles2rice to be a lot better than gles2n64 with regards to accuracy (I'll likely make it the default video plug-in when the slow-speed problem has been improved).  Like scorpio16v said, though, it will be painfully time consuming on your device, so no worries if you don't have the time for this (I'll get around to doing more comparison tests when I move to the beta testing phase).
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 20, 2011, 01:26:39 PM
I know why you did i was asking bubble a rhetoricle question :)
I will thouroughly test rice after you finish the ui
one question though. I'm sure you know about the icontrolpad, are you planing to ad support for it? Or is there already a way that i haen't found yet?
Title: Re: Alpha Testing Underway!
Post by: nscxp2005 on November 20, 2011, 01:36:07 PM
Hi Paul,

I was just wondering. In the official build of the GUI with it have Xperia Play Touch Pad support?

Excellent progress on the emulator.

Keep up the fantastic work.

All the best]

NSCXP2005
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 20, 2011, 01:43:36 PM
The icontrolpad works fine with bluezIME.
You can map all buttons incl. the analog sticks, but you can use the sticks only for digital button press. So there is no way to walk slow with mario, for example.
As long as an emulator supports button-mapping, the iControllpad and bluezIME will work.
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 20, 2011, 02:08:28 PM
The icontrolpad works fine with bluezIME.
You can map all buttons incl. the analog sticks, but you can use the sticks only for digital button press. So there is no way to walk slow with mario, for example.
As long as an emulator supports button-mapping, the iControllpad and bluezIME will work.
thanks! But i was really hopeing for analogue :( any way you can do that paul?
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 20, 2011, 02:37:01 PM
Hi Paul,

I was just wondering. In the official build of the GUI with it have Xperia Play Touch Pad support?

Excellent progress on the emulator.

Keep up the fantastic work.

All the best]

NSCXP2005

Paul did say a while back that he wont be maintaining the xperia touchpad brach of the emulator but that he would compile a build once the GUI was done.

There are also instructions on the opening post on how to implement the controls to the newest builds yourself, If you know how to compile code then its not too hard to do.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 20, 2011, 02:37:34 PM
I was just wondering. In the official build of the GUI with it have Xperia Play Touch Pad support?
Once I've debugged the GUI, I'll add it to the Xperia Play branch and list both on the market (and they'll both be available here too, along with the source code of course).

But i was really hopeing for analogue :( any way you can do that paul?
BluezIME is open-source, so yes.  Basically, I'd need to take the components of BluezIME that interpret the input, and instead of converting it into keyboard input, convert it into N64 input directly (i.e. a special input plug-in).  This is on my to-do list for some point in the future.
Title: Re: Alpha Testing Underway!
Post by: nscxp2005 on November 20, 2011, 02:43:25 PM
Once I've debugged the GUI, I'll add it to the Xperia Play branch and list both on the market (and they'll both be available here too, along with the source code of course).

Excellent, Thank you Paul.

Much appreciated.

PS So does that mean with every new release of the emulator there will be a version with Xperia Play controls added?
Title: Re: Alpha Testing Underway!
Post by: Paul on November 20, 2011, 03:15:23 PM
So does that mean with every new release of the emulator there will be a version with Xperia Play controls added?
Depends on the changes.  For changes to the Java components, probably not every new update just because it is fairly tedious to maintain two of everything.  For changes to the plug-ins and core (which most updates will be focused on anyway), that is much easier (I can link both projects to the same native libraries, so both benefit from any changes).
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 20, 2011, 03:18:40 PM
Hey paul, can you give us a "precise" percentage of what's done in the gui and what you will add after you complete the basic gui? Also: you said we can use our own skins for buttons etc, will we have in the menu button a way to move the buttons quickly without having to go  in the main menu?
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 20, 2011, 03:23:27 PM
I also have a small question. :)

How easy do you think is would be to port your emulator to other platforms such as IOS and webOS? The way this emulator has been created seems very tightly integrated with the way android works so im kinda guessing a lot would need to be re-done.
Title: Re: Alpha Testing Underway!
Post by: Mats on November 20, 2011, 03:30:25 PM
what you doing now with the emulator ;)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 20, 2011, 03:56:14 PM
Hey paul, can you give us a "precise" percentage of what's done in the gui and what you will add after you complete the basic gui?
The basic GUI is basically written.  There are just the couple things that are broken which I mentioned earlier.  After that I have to put it all together and arrange the code in a way that other developers can follow and comment it.  Another 2 or 3 evenings of work is probably all I'll need to finish it  Sorry, I have a really bad track record of underestimating how long things take, and it also varies depending on what's going on in "real-life" (my job in particular).

Also: you said we can use our own skins for buttons etc, will we have in the menu button a way to move the buttons quickly without having to go  in the main menu?
No, the skins will be static in-game.  Rearranging buttons will require manually editing the pad.ini file until I create a Skin Editor program at some point.

How easy do you think is would be to port your emulator to other platforms such as IOS and webOS? The way this emulator has been created seems very tightly integrated with the way android works so im kinda guessing a lot would need to be re-done.
Basically all of the Java components and the JNI linkage (which includes the touchscreen and key input, on-screen joystick, EGL context, and the GUI - something like 50% of the stuff added to the original Mupen64Plus and Ari64's dynarec).  These ports would a fairly large projects in themselves, but certainly easier than starting completely from scratch.  I don't own an "I" device, so I don't have any plans to tackle such a project at the moment.

what you doing now with the emulator ;)
Nothing.. I'm at work right now.  I'll get back to it some more when I get home this evening.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 20, 2011, 04:19:05 PM
Quote
Basically all of the Java components and the JNI linkage (which includes the touchscreen and key input, on-screen joystick, EGL context, and the GUI - something like 50% of the stuff added to the original Mupen64Plus and Ari64's dynarec).  These ports would a fairly large projects in themselves, but certainly easier than starting completely from scratch.  I don't own an "I" device, so I don't have any plans to tackle such a project at the moment.

Thanks for your answer, I wanted to know because iOS is one of the only mobile platforms left without a decent n64 emulator, n64iphone is very very slow and limited (Cant use all n64 buttons, no landspace etc). I never expected you to have a go at porting it to iOS but Maybe at some point in the future another dev could use your source code and give it a try. iOS isnt the best platform for emulation anyway, having to jailbreak the phone in order to install emulators is a really big pain especially since newer iDevices cant be jailbroken. xD

Android is pretty much the best mobile operating system when it comes to emulation right now, the only thing better are the desktop OS's like windows and ubuntu.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 20, 2011, 08:04:34 PM
iOS isnt the best platform for emulation anyway, having to jailbreak the phone in order to install emulators is a really big pain especially since newer iDevices cant be jailbroken. xD

That's a good point.  On top of that, it is technically illegal to distribute ANY app which is licensed by the GPL for IDevices, because it violates their "usage rules" agreement.  The "usage rules" themselves violate one of the requirements in paragraph 6 of the GPL:

Quote
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 21, 2011, 12:48:44 AM
Paul, you're an awesome programmer, you ported one of the best n64 emulators in the world it and after it you will port a dreamcast eemulator, I want to learn programming in some way, with what should I start learning? (I'm a Mac) (I can also model)
wow just some days and your GUI will be done, awesome!
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 21, 2011, 01:55:09 AM
Paul, you're an awesome programmer, you ported one of the best n64 emulators in the world it and after it you will port a dreamcast eemulator, I want to learn programming in some way, with what should I start learning? (I'm a Mac) (I can also model)
wow just some days and your GUI will be done, awesome!

Pauls answer will differ from mine but I think easiest way to get started was to use visual basic, unfortunately its windows only but some of the things you can learn from visual basic can help you get to grips with the basics of programming. After that I moved onto java which admittedly is much more complex but also a very useful programming language to learn.

Also I dont know why but I love IF statments :P
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 21, 2011, 07:41:37 AM
Pauls answer will differ from mine but I think easiest way to get started was to use visual basic, unfortunately its windows only but some of the things you can learn from visual basic can help you get to grips with the basics of programming. After that I moved onto java which admittedly is much more complex but also a very useful programming language to learn.

Also I dont know why but I love IF statments :P
people says that python is an easy language, it's a language used in Macs too, or i could just try to get visual basic on Mac, there surely should be a way

p.s: if if if if if if if if if if if :3
Title: Re: Alpha Testing Underway!
Post by: Mats on November 21, 2011, 10:43:25 AM
wich cam have u used on the pictures on the first site paul ? it looks really nicce :D
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 21, 2011, 10:49:41 AM
wich cam have u used on the pictures on the first site paul ? it looks really nicce :D

Do you mean the pics on the first page of this thread? Most of those pics were taken using screenshot software (Just like using the screenshot button on a desktop computer) and the Pic of the xperia play was taken by me using my iPhone 3GS.
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 21, 2011, 12:45:44 PM
Where should I go to get the settings to disable audio? Audio got boring, it's just damn beatboxing :D
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 21, 2011, 01:56:26 PM
Where should I go to get the settings to disable audio? Audio got boring, it's just damn beatboxing :D

You need a rooted phone to do this but you have to delete this file
/data/data/paulscode.android.mupen64plus/lib/libaudio-sdl.so

Removing that will disable the audio and speed up emulation a bit.
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 21, 2011, 03:24:45 PM
Where should I go to get the settings to disable audio? Audio got boring, it's just damn beatboxing :D

You need a rooted phone to do this but you have to delete this file
/data/data/paulscode.android.mupen64plus/lib/libaudio-sdl.so

Removing that will disable the audio and speed up emulation a bit.

ok. i will just wait for the GUI, don't want to crash my smartphone with any error  :P
Title: Re: Alpha Testing Underway!
Post by: Paul on November 21, 2011, 03:37:25 PM
I want to learn programming in some way, with what should I start learning? (I'm a Mac)

A lot of people will recommend taking classes, but I am self-taught so I recommend teaching yourself (it's much cheaper and more effective because you have to learn to work through problems on your own).  On a Windows machine, I would start with Visual Basic, but on a non-Windows machine, I would start with Python.

1) Begin by working through some tutorials (there are tons of them all over the internet for free at various difficulty levels).  If one is too hard, bookmark to it, and keep looking (then come back to it when you have improved).  It might seem tedious, but you're going to want to do a LOT of tutorials to get the feel for "thinking like a programmer".  It doesn't come naturally - takes lots of practice.

2) Once you are very comfortable doing the tutorials, come up with several of your own projects (start simple and work your way to more difficult things).  This will solidify what you learned by copying other peoples code, and give you the skill of being able to turn new ideas into code.  Join several programming forms and ask for help when you get stumped.  If you find that you are struggling particular concepts, be sure to spend extra time practicing those.  Do this until you feel comfortable "thinking like a programmer".

3) Next, begin working through Java tutorials.  In my opinion, Java is the most user-friendly object-oriented programming language out there.  Its basic similarity to C/C++ is also a huge bonus, because those languages are your ultimate goal.  As you did earlier, start with simple and work your way up to the difficult concepts.  Spend some extra time on Threads and synchronization (it's easier to learn this in Java than in C/C++).

4) Come up with several of your own Java projects.  Do this until you feel comfortable with the "object oriented" concept to programming.  If you have a particular area of programming you want to head toward (such as game development), then give yourself at least one big project related to that subject (just to get your mind thinking in the right direction, and it will be a lot more fun than doing random irrelevant projects)

5) Next, begin working through C++ tutorials.  The main thing you will want to focus on here is using pointers, structs, and classes (these are quite different than Java, and will probably take some time to get used to).  Also spend extra time learning how to debug C++.

6) Finally, begin working though some C tutorials.  Most large native projects include both C and C++ source code, so although they are very similar, understanding the differences is important (spending a little extra time on this right up front will save you a lot of headache later).

7) Now you are ready to work toward your original goal (it will probably be several months to get to this point, but well worth it).  If your goal was a game, then start by learning the basic components you will need (such as audio, 2D graphics, 3D, and so on).  Give yourself small projects to learn these concepts, and when you are ready, jump right into your main project.  Expect to spend at least a year on a worthwhile project, especially if you are still new to that particular subject.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 21, 2011, 03:53:53 PM
wich cam have u used on the pictures on the first site paul ? it looks really nicce :D

The ones that I took, I used the Screen Capture function in DDMS.  It's one of the debug tools in the Android SDK.
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 22, 2011, 12:50:02 AM
All Paul said
Thanks Paul for the detailed answer, when I read scripts I understand them, is it a good thing or everyone without programming experiences can? after I learn most of programming I want to help you with the emulators in any way :D
Title: Re: Alpha Testing Underway!
Post by: nscxp2005 on November 22, 2011, 08:14:34 AM
Hi  Epic_bubble and Paul,

Would it be possible if you could make me a copy of the latest version with Xperia Touch Pad Support?

I have not long since got my Xperia Play and would like to test how is works with the emulator.

Thank you for your time

All the best,

NSCXP2005
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 22, 2011, 08:29:25 AM
Hey Im not why you mentioned me since only paul is the one creating the emulator but for the meantime you can use this build: http://www.paulscode.com/source/Mupen64Plus-AE/27OCT2011/Mupen64Plus-Xperia-Play-debug.apk

It has touchpad support but no GUI. Hope this helps. :)
Title: Re: Alpha Testing Underway!
Post by: VioletLinked on November 22, 2011, 10:18:01 AM
Before I forget, happy Thanksgiving and black Friday guys!
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 22, 2011, 02:44:48 PM
@ Paul
Have you seen yongzh updated source from 10/11. November ?

http://sourceforge.net/projects/n64oid/files/

But don't expect anything usefull.  ::)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 22, 2011, 04:35:53 PM
@ Paul
Have you seen yongzh updated source from 10/11. November ?

http://sourceforge.net/projects/n64oid/files/

But don't expect anything usefull.  ::)

The main change in this source-code update is that Yongzh removed his gles2n64 source.  This is really sad, because he fixed a lot of problems, and now all that work is basically lost to the open-source community.

Besides that, there have been three changes:

1) Speed Factor.  This seems to be similar to "Fast Forward", except it allows you to specify an arbitrary percentage (so could also be used to "Slow Down" as well).  However, all the useful stuff has been moved to the audio plug-in (to keep it closed-source), so there's nothing useful I can use here.

2) GameShark Button.  I'm not familiar with what this does, but I don't see a lot of new code related to it, so I'd guess most of the useful stuff for this is also in the closed-source sections (I'll look at this more closely at some point).

3) Cheats.  Processing seems to have been moved to its own separate thread.  Most if not all the code for this seems to be present, so this is probably something I can use.  I'll have to look at it a little more closely, though to see if anything important is missing.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 22, 2011, 04:48:58 PM
Would it be possible if you could make me a copy of the latest version with Xperia Touch Pad Support?
The touchpad example linked to in the first post is nearly up-to-date, and fine for testing.  The only things missing are the Rice video plug-in (which is not complete), the in-game menu (which only gives you the ability to save/load state, and can alternatively be done with button mapping), and the hardware profiling logic (which is irrelevant for the Xperia Play version).  When I finish the GUI, I'll release an Xperia Play version.  If you need the Rice video plug-in and your device is rooted, just save the file libgles2rice.so from the non-Xperia Play build, and then after installing the Xperia Play version, stick it into /data/data/paulscode.android.mupen64plus/lib
Title: Re: Alpha Testing Underway!
Post by: Paul on November 22, 2011, 08:05:05 PM
One of the things I thought of to add to the core settings view is an option to "Set arguments".  This will provide an easy way to use special Mupen64Plus features without me having to create a special interface for every one of them (cheats for example).
Title: Re: Alpha Testing Underway!
Post by: VioletLinked on November 22, 2011, 10:51:22 PM
Just to get this stright really quick:

The GUI will have a menu which will let you...
>Turn on and off volume control with volume buttons
>Turn Xperia play touch pad support on and off (I know you said it will no longer be supported, but if you put  Mupen64plus AE in the market, do this)
>Save and Load States
>Button Mapping
>Game Overlay Chooser
>Set Aurguments / Cheats
>Information
Title: Re: Alpha Testing Underway!
Post by: Paul on November 22, 2011, 11:45:26 PM
Everything there except that Xperia Play touch pad support will be a separate app (I'll list both on the market) and "Arguments/ Cheats" is just "Arguments" (can be used to enable cheats and anything else you can do with command-line arguments).  Also, I haven't added "Information", but that's a good one  :)
Title: Re: Alpha Testing Underway!
Post by: nscxp2005 on November 23, 2011, 07:17:59 AM
Hey Im not why you mentioned me since only paul is the one creating the emulator but for the meantime you can use this build: http://www.paulscode.com/source/Mupen64Plus-AE/27OCT2011/Mupen64Plus-Xperia-Play-debug.apk

It has touchpad support but no GUI. Hope this helps. :)

Hi Epic_Bubble,

Sorry for asking you. I asked because you have an Xperia Play and I thought you would understand more on how to add the support in to the emulator.

Thank you for the file.

It is much appreciated.

Thank you for your time.

All the best,

NSCXP2005
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 23, 2011, 09:35:04 AM
so how would the arguments menu work? ik for cheats u do -cheat0, -cheat1 etc but would it list the cheats and let u enable them with a menu or what. i also find it neccessary to be able to disable cheats during gameplay
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 23, 2011, 10:20:15 AM
Arguments should be the same as the original mupen64plus right? Also do any of the open source graphic plugins have the ability to change the internal resolutions of the games? For now it looks like the emulator renders the game at your devices native screen res, if the internal res could be changed to force it lower then maybe older phones would get a bit of a speed up.

I have an old crappy netbook lying about and by lowering the internal resolution on project64 I have had massive speed gains (although a loss of picture quality). 
Title: Re: Alpha Testing Underway!
Post by: koekje on November 23, 2011, 10:39:55 AM
For rooted devices you can also use Chainfire 3D it alows you tu use
 16bit textures, i dont notice much on my phone since the emulator runs good on my phone. But i think it will work great on the slower devices.

(Make sure your device is supported for this!)
Title: Re: Alpha Testing Underway!
Post by: Paul on November 23, 2011, 01:28:20 PM
so how would the arguments menu work? ik for cheats u do -cheat0, -cheat1 etc but would it list the cheats and let u enable them with a menu or what. i also find it neccessary to be able to disable cheats during gameplay
No, arguments will just be plain old command-line arguments, and will only go into affect when the emulator starts (no capability to change them once the game has started).  A cheats menu will be added at some point in the future, but it is fairly low on my priority list because I don't really use cheats (another developer may tackle it if it is important to them).

Also do any of the open source graphic plugins have the ability to change the internal resolutions of the games? For now it looks like the emulator renders the game at your devices native screen res, if the internal res could be changed to force it lower then maybe older phones would get a bit of a speed up.
I'm not familiar with gles2rice, but gles2n64 does not let you change the resolution of the game, however it does let you change the rendered resolution.  This of course would mean that lowering the resolution would also make the rendered frame smaller, but it would probably provide a performance boost on lower-end devices or higher-end games.  It may be possible to do a resolution change via Java when setting up EGL - I'll have to look into this.  Either way, I'll add a configuration menu for this at some point (this will come after I write a standard API in Java for the plug-in configuration menus to use - so developers can add their own plug-in specific configurations that will show up in the API)
Title: Re: Alpha Testing Underway!
Post by: Mats on November 23, 2011, 01:30:18 PM
gui will be awensome !
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on November 23, 2011, 01:56:34 PM
Quote
I'm not familiar with gles2rice, but gles2n64 does not let you change the resolution of the game, however it does let you change the rendered resolution.  This of course would mean that lowering the resolution would also make the rendered frame smaller, but it would probably provide a performance boost on lower-end devices or higher-end games.  It may be possible to do a resolution change via Java when setting up EGL - I'll have to look into this.  Either way, I'll add a configuration menu for this at some point (this will come after I write a standard API in Java for the plug-in configuration menus to use - so developers can add their own plug-in specific configurations that will show up in the API)

Ops thats what I meant by internal resolution :P

Ive seen PC emulators in the past that somehow keeps your devices screen res the same but the actual emulations res is lower... its hard to explain but you know what I mean. :)

An example of this is the wii emulator called dolphin, the emulators window fits the whole screen and is displayed in 1920x1080 but the actual emulation going on inside that window is only something like 800x600, which makes the game look a little pixelated but it runs much faster while still being displayed full screen .
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 24, 2011, 10:26:13 PM
Anything to improve speed :)
One thing i would like to see is accelerometer controls. For games like f-zero x
Title: Re: Alpha Testing Underway!
Post by: Paul on November 25, 2011, 07:54:27 AM
One thing i would like to see is accelerometer controls. For games like f-zero x

The input-sdl plug-in recognizes "Android accelerometer" as a joystick, but it would need a profile added to InputAutoCfg.ini.  It has 3 axes (x-axis, y-axis, and z-axis) and no buttons.  It records the affect of gravity (so lying screen-up on a level surface would record analog input in the -z direction, tilted on its right side would record analog input in the +x direction, etc.).

Anyway, to get it working in the emulator, you'd just have to add a profile for it to InputAutoCfg.ini.  If you're interested in working on that yourself, I can provide you a simple app that prints the accelerometer values to logcat, which you can use to determine the values to use for AnalogDeadzone and AnalogPeak (will require a bit of trial and error to get it right).  If you can figure out a profile that works well, I'll add it later (after I make the plug-in configurable through the GUI, so it doesn't always use the accelerometer as a joystick every time).
Title: Re: Alpha Testing Underway!
Post by: Paul on November 26, 2011, 09:48:11 PM
I've been doing some testing of the plug-in choosing code, and decided to build a version of the core with RDRAM at the N64 native RAM address of 0x80000000.  This optimization should noticeably improve performance, but will probably not work on most devices.  Anyway, I thought I would put it out there in case some folks with rooted devices want to give it a shot.  I was going to run this particular test at a later date, but I'm kind of curious if it will work for anyone at all, or if Android is doomed to always have something loaded at that memory location.

Core w/ RDRAM at Native Address (http://www.paulscode.com/source/Mupen64Plus-AE/26NOV2011/mupen64plus-core-noTLB)

First, install the "official build" from the initial post (to rule out any bugs with the incomplete resume code).  Then, unzip the above zip file and grab the version of libcore.so for your device (ARM7 or pre-ARM7).  Paste it over the existing /data/data/paulscode.android.mupen64plus/lib/libcore.so.  If the emulator doesn't run, please post the generated file DEBUG_PluginTestA_memoryMaps.txt and logcat output.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 26, 2011, 11:23:00 PM
Got it. Didn't work.on xperia play
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on November 27, 2011, 01:13:20 AM
you are trying to start code in an area where system libarys are located ?  :o
or did I misread the memorydebug.txt ?
i've problems to add a second logcat, so here is the sgs2 output from my dropbox.

http://db.tt/bywgw5Wi
Title: Re: Alpha Testing Underway!
Post by: Paul on November 27, 2011, 07:06:44 AM
you are trying to start code in an area where system libarys are located ?  :o
or did I misread the memorydebug.txt ?
Yep, that's correct.  It won't work for most devices for that reason, but I'm curious if it will work for any device.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 27, 2011, 07:24:21 AM
Got it. Didn't work.on xperia play

From the memory maps, it looks like it should work on your device (nothing is reported to be loaded at 0x80000000, so in theory I should be able to use it).  Let me see if I have a typo somewhere in the code (I'm programming "blind" again, since it doesn't work on my Droid X).  I'm wondering if this has something to do with some limitations Android might be placing on the app from just accessing an arbitrary memory address (for security purposes).
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 27, 2011, 08:22:27 AM
ok i noticed something, the permissions of the new core were set to 666 so it couldnt execute the code. I changed them to 777 and instead of crashing, it just hangs on the screen and gives me not responding messages.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 27, 2011, 08:39:05 AM
ok i noticed something, the permissions of the new core were set to 666 so it couldnt execute the code. I changed them to 777 and instead of crashing, it just hangs on the screen and gives me not responding messages.
Oh, ok.  Could you post another logcat from when it's having that behavior?  I'll probably just continue these tests after I post the next official build (I've been a little burned out working on the GUI, and got side-tracked with other components of the emulator this weekend).
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 27, 2011, 01:58:05 PM
Ok here.
Title: Re: Alpha Testing Underway!
Post by: dustarma on November 27, 2011, 02:13:57 PM
It crashed when loading the ROM, here's the output.

*edit* The attachment system seems to be broken, it's downloading index.php files *edit*

http://dl.dropbox.com/u/28439034/DEBUG_PluginTestA_memoryMaps.txt

here's an alternate link.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 27, 2011, 04:18:17 PM
Ok here.
Weird.  Is that the entire logcat output? (seems to be, judging from the alogcat messages)  The very first thing the app should do is link with the libSDL.so library, but even that doesn't seem to be happening.  The following line says the app is running (although not responding):
Code: [Select]
I/InputDispatcher(  175): Application is not responding: AppWindowToken{2b694c38 token=HistoryRecord{2b3e2870 paulscode.android.mupen64plus/.SDLActivity}}.  5004.8ms since event, 5004.5ms since wait started
I wonder if it is just smart enough to know the .so library was swapped out so it won't let it run?  I guess I'll have to do these tests later after I finish putting the code back together so I can release them as complete APKs instead of a .so library.

It crashed when loading the ROM, here's the output.

*edit* The attachment system seems to be broken, it's downloading index.php files *edit*

http://dl.dropbox.com/u/28439034/DEBUG_PluginTestA_memoryMaps.txt

here's an alternate link.
Unfortunately it looks like on your device, it has libskiagl.so loaded at 0x80000000, so this optimization won't work in your case.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 27, 2011, 04:23:32 PM
*edit* The attachment system seems to be broken, it's downloading index.php files *edit*

The attachment links aren't actually to the file directly, but rather are to send a command to index.php to download the file.  Specifically, the links look like this:
Code: [Select]
path/to/index.php?action=dlattach;topic=##;attach=##
So if you were to right-click and choose "save link as", you'd just get "index.php".  I'd guess something like this is what was happening.
Title: Re: Alpha Testing Underway!
Post by: dustarma on November 28, 2011, 08:57:38 AM
*edit* The attachment system seems to be broken, it's downloading index.php files *edit*

The attachment links aren't actually to the file directly, but rather are to send a command to index.php to download the file.  Specifically, the links look like this:
Code: [Select]
path/to/index.php?action=dlattach;topic=##;attach=##
So if you were to right-click and choose "save link as", you'd just get "index.php".  I'd guess something like this is what was happening.

Actually I'm getting the index.php file by left-clicking on it, like any other link.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 28, 2011, 03:59:18 PM
Weird.  What are your OS and browser versions?
Title: Re: Alpha Testing Underway!
Post by: dustarma on November 28, 2011, 09:37:06 PM
Windows 7 x64 and Firefox 8.

*EDIT* It seems to work fine on Google Chrome 15 *EDIT*
Title: Re: Alpha Testing Underway!
Post by: Paul on November 29, 2011, 05:03:47 AM
I did a little googling.. this seems to be a known bug in Firefox 8 with SMF 2.0 and some other php-based programs.  I'd guess it will be fixed fairly quickly, since a fairly significant percentage of the web is using SMF.  Until then, there seems to be a mod that can be applied to SMF to fix the issue, so I'll look into that later (the link I found to it was broken).
Title: Re: Alpha Testing Underway!
Post by: Mats on November 29, 2011, 09:42:11 AM
then should i use google chrome or internet explorer 9 ?? :D
Title: Re: Alpha Testing Underway!
Post by: Mats on November 29, 2011, 09:43:03 AM
new official build ? ;)
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on November 29, 2011, 02:44:45 PM
then should i use google chrome or internet explorer 9 ?? :D

NEVER USE INTERNET EXPLORER, it's the 1st browser giving you a lot viruses, also it's slow, i vote for chrome (or get safari)
Title: Re: Alpha Testing Underway!
Post by: Mats on November 29, 2011, 03:03:13 PM
then should i use google chrome or internet explorer 9 ?? :D

NEVER USE INTERNET EXPLORER, it's the 1st browser giving you a lot viruses, also it's slow, i vote for chrome (or get safari)
OoO i thongt that it was the most secure browser :o
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 29, 2011, 03:12:41 PM
ie is the worst browser out there. If you want a lot of addons get firefox, if you want a rlly fast browser get chrome
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 29, 2011, 04:53:59 PM
yea just get chrome. it has a decent number of extensions and lots of cool built in google stuff.

One thing i would like to see is accelerometer controls. For games like f-zero x

The input-sdl plug-in recognizes "Android accelerometer" as a joystick, but it would need a profile added to InputAutoCfg.ini.  It has 3 axes (x-axis, y-axis, and z-axis) and no buttons.  It records the affect of gravity (so lying screen-up on a level surface would record analog input in the -z direction, tilted on its right side would record analog input in the +x direction, etc.).

Anyway, to get it working in the emulator, you'd just have to add a profile for it to InputAutoCfg.ini.  If you're interested in working on that yourself, I can provide you a simple app that prints the accelerometer values to logcat, which you can use to determine the values to use for AnalogDeadzone and AnalogPeak (will require a bit of trial and error to get it right).  If you can figure out a profile that works well, I'll add it later (after I make the plug-in configurable through the GUI, so it doesn't always use the accelerometer as a joystick every time).
I don't think i'm committed or patient enough for that.. and i don't want you to go through the trouble of giving me all the tools if I'm never really going to use them.
 
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 29, 2011, 05:11:56 PM
Hey I retested the new core and it actually loads.  Crashes though... here's the logcat
Title: Re: Alpha Testing Underway!
Post by: Paul on November 29, 2011, 07:45:19 PM
Hey I retested the new core and it actually loads.  Crashes though... here's the logcat
That's interesting.  I build a version thats a bit more verbose, to rule out a couple of potential problems and see how far it gets into the code.  Could you post the logcat after loading this one? (will need execute permission set again, since ZIP doesn't seem to save that):

Core w/ RDRAM at Native Address, verbose (http://www.paulscode.com/source/Mupen64Plus-AE/29NOV2011/mupen64plus-core-noTLB)

I know I'm on a bit of a tangent with this, but I'm still a bit burned out with the GUI (I'll get back to finishing it up soon).
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 29, 2011, 08:27:43 PM
Here:
Title: Re: Alpha Testing Underway!
Post by: Paul on November 29, 2011, 08:44:13 PM
Yep, there's the problem:
Code: [Select]
V/core    ( 2542): rdram=-1006632960
Now I just have to figure out where it came up with that number (0xc4000000 in hex)..
Title: Re: Alpha Testing Underway!
Post by: Paul on November 29, 2011, 08:58:30 PM
Here:
Ok, post the logcat for this one:

Core w/ RDRAM at Native Address, verbose (#2) (http://www.paulscode.com/source/Mupen64Plus-AE/29NOV2011/mupen64plus-core-noTLB-2)
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 29, 2011, 09:10:52 PM
Got it
Title: Re: Alpha Testing Underway!
Post by: Paul on November 29, 2011, 09:14:52 PM
Fixed that problem.  Time to do some more digging.

--EDIT-- That is really strange.  Addr2line for 0002ac38 indicates that the problem occurs at this line of code:
Code: [Select]
*((unsigned int *)(rdramb + (address & 0xFFFFFF))) = word;
The following output indicates that the cause of the problem is an attempt to access memory address 0x80000004:
Code: [Select]
I/DEBUG   (  100): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 80000004
The code where the RAM is mmapped:
Code: [Select]
    printf( "rdram=0x%x", (int)rdram );
    printf( "munmapping" );
    munmap ((void*)0x80000000, 0x800000);
    printf( "mmapping" );
    if( mmap ((void*)0x80000000, 0x800000,
        PROT_READ | PROT_WRITE,
        MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS,
        =1, 0) <= 0) {printf( "map(0x80000000) failed");}
    else
        printf( "done mmapping" );

And the following output indicates that the memory allocation was successful and in the correct location:
Code: [Select]
V/core    ( 4947): rdram=0x80000000
V/core    ( 4947): munmapping
V/core    ( 4947): mmapping
V/core    ( 4947): done mmapping

So why does it fail to write a mere word of data at 0x80000004 if 0x800000 bytes of memory have been allocated starting from 0x80000000, I wonder?  Maybe I should test that I can write to this area immediately after allocating it, to determine if I'm being prevented from writing there, or if the problem crops up later.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 29, 2011, 10:02:44 PM
Ok, last one for today.  Output from this one should tell me whether the problem starts immediately after allocating the memory, or if it is introduced later:

Core w/ RDRAM at Native Address, verbose (#3) (http://www.paulscode.com/source/Mupen64Plus-AE/29NOV2011/mupen64plus-core-noTLB-3)
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 29, 2011, 10:21:41 PM
Done. Im excited about this new core :D. Probably make Banjo Tooie crash less lol
Title: Re: Alpha Testing Underway!
Post by: Mats on November 30, 2011, 01:25:17 PM
gui ??
Title: Re: Alpha Testing Underway!
Post by: TFreestone on November 30, 2011, 03:07:19 PM
chill bro. he'll be done when he's done
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 30, 2011, 05:43:21 PM
I got my friend to test this app out on a http://www.lg.com/us/mobile-phones/LG-VM670.jsp (http://www.lg.com/us/mobile-phones/LG-VM670.jsp) phone and it works pretty well. he overclocked it to 748mhz.
Title: Re: Alpha Testing Underway!
Post by: Paul on November 30, 2011, 08:47:05 PM
Done. Im excited about this new core :D. Probably make Banjo Tooie crash less lol

Looking at your memory map again, I can see another possible optimization I could add as well for the XPeria Play (this phone just keeps looking better and better..)  It would require building the core as a static library (preventing it from being swapped out, but possibly worth it if the improvement is significant enough).  I'll try and get this other optimization going first, though.

This segfault doesn't seem to be a problem with the core per se - it appears to be crashing in some extremely basic c code.. I'm not sure why (probably something simple I'm missing).  I'm going to ask around for some advice on other forums.  Let me make sure I'm understanding where the problem happens, first.  Please post another logcat for this build:

Core w/ RDRAM at Native Address, verbose (#4) (http://www.paulscode.com/source/Mupen64Plus-AE/30NOV2011/mupen64plus-core-noTLB.zip)


In case anyone here can spot the problem, the code leading up to the crash is here:
Code: [Select]
// rdram is defined in header as:  #define rdram ((unsigned int *)0x80000000)
     printf( "munmapping" );
     munmap ((void*)0x80000000, 0x800000);
     printf( "mmapping" );
     if(mmap ((void*)0x80000000, 0x800000,
            PROT_READ | PROT_WRITE,
            MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS,
            -1, 0) <= 0)
     {
         printf( "mmap(0x80000000) failed" );
     }
     else
     {
         for (i=0; i<(0x800000/4); i++)
         {
             printf( "writing a zero at 0x%x", (0x80000000 + i) );
             rdram[i]=0;    // <<---------SEGFAULT HERE--------<<
}
         printf( "done writing zeros" );
      }
Title: Re: Alpha Testing Underway!
Post by: xperia64 on November 30, 2011, 09:04:59 PM
Got it.
Title: Re: Alpha Testing Underway!
Post by: nscxp2005 on December 01, 2011, 08:39:39 AM
Xperia64,

Which libcore are you using? is it ARM7 or Pre-ARM7?

All the best,

NSCXP2005
Title: Re: Alpha Testing Underway!
Post by: DJKBER on December 01, 2011, 09:43:52 AM
THANK!
Title: Re: Alpha Testing Underway!
Post by: MaXiMu on December 01, 2011, 09:55:18 AM

Tested new core #4 close/resume And not work on Imap (armv6)

Code: [Select]
V/SDLActivity(22018): SDLSurface new instance
D/dalvikvm(22018): GC_FOR_MALLOC freed 7492 objects / 537976 bytes in 56ms
I/global  (22018): Default buffer size used in BufferedReader constructor. It wo
uld be better to be explicit if an 8k-char buffer is required.
I/global  (22018): Default buffer size used in BufferedReader constructor. It wo
uld be better to be explicit if an 8k-char buffer is required.
V/GamePad (22018): Mupen64Plus AE Analog Touch
V/GamePad (22018):     ver 1.0
V/GamePad (22018):     Analog gamepad with a clean, intuitive layout
V/GamePad (22018):     Author: roymustang16 and Paul Lamb
D/dalvikvm(22018): GC_FOR_MALLOC freed 1183 objects / 271936 bytes in 49ms
D/dalvikvm(22018): GC_EXTERNAL_ALLOC freed 22 objects / 17872 bytes in 46ms
D/dalvikvm(22018): GC_EXTERNAL_ALLOC freed 167 objects / 337968 bytes in 47ms
V/SDLActivity(22018): SDLSurface created
V/SDLActivity(22018): SDLSurface changed
V/SDL     (22018): pixel format OPAQUE (using SDL_PIXELFORMAT_RGB565)
V/SDLActivity(22018): Starting new SDLMain() thread
I/SDL     (22018): SDL_Android_Init()
V/front_end(22018):  __  __                         __   _  _   ____  _

V/front_end(22018): |  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ __
_
V/front_end(22018): | |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / _
_|
V/front_end(22018): | |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__
 \
V/front_end(22018): |_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|__
_/
V/front_end(22018):              |_|         http://code.google.com/p/mupen64plu
s/
V/front_end(22018): Mupen64Plus Console User-Interface Version 1.99.4
V/front_end(22018):
V/core_interface(22018): UI-console: attached to core library 'Mupen64Plus Core'
 version 1.99.4
V/core_interface(22018):             Includes support for Dynamic Recompiler.
I/DEBUG   (17146): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *
**
I/DEBUG   (17146): Build fingerprint: 'NBPC/AIRIS/AIRIS/:2.2/FRF85B/eng.liuqi.20
110719.192824:user/test-keys'
I/DEBUG   (17146): pid: 22018, tid: 22036  >>> paulscode.android.mupen64plus <<<

I/DEBUG   (17146): signal 11 (SIGSEGV), fault addr 00000000
I/DEBUG   (17146):  r0 00000009  r1 00000001  r2 487f8b3c  r3 00000000
I/DEBUG   (17146):  r4 487f8b68  r5 00000004  r6 43e1338a  r7 43a4ffc8
I/DEBUG   (17146):  r8 487f8b48  r9 43a4ffc0  10 43a4ffac  fp 487f8ed8
I/DEBUG   (17146):  ip 81d03629  sp 487f8b38  lr 81d03643  pc 00000000  cpsr 200
00010
I/DEBUG   (17146):          #00  pc 00000000
I/DEBUG   (17146):          #01  pc 00003640  /data/data/paulscode.android.mupen
64plus/lib/libmain.so
I/DEBUG   (17146):          #02  pc 00011034  /system/lib/libdvm.so
I/DEBUG   (17146):          #03  pc 0003e8cc  /system/lib/libdvm.so
I/DEBUG   (17146):          #04  pc 00043de0  /system/lib/libdvm.so
I/DEBUG   (17146):          #05  pc 00015fa8  /system/lib/libdvm.so
I/DEBUG   (17146):          #06  pc 0001c9c0  /system/lib/libdvm.so
I/DEBUG   (17146):          #07  pc 0001b864  /system/lib/libdvm.so
I/DEBUG   (17146):          #08  pc 00054b8a  /system/lib/libdvm.so
I/DEBUG   (17146):          #09  pc 00054da2  /system/lib/libdvm.so
I/DEBUG   (17146):          #10  pc 00048d7e  /system/lib/libdvm.so
I/DEBUG   (17146):          #11  pc 00011198  /system/lib/libc.so
I/DEBUG   (17146):          #12  pc 00010c7c  /system/lib/libc.so
I/DEBUG   (17146):
I/DEBUG   (17146): code around pc:
I/DEBUG   (17146):
I/DEBUG   (17146): code around lr:
I/DEBUG   (17146): 81d03620 00005212 00000194 b083b500 4b0c2200
I/DEBUG   (17146): 81d03630 4a0c9201 2009447b 2101589b 681baa01
I/DEBUG   (17146): 81d03640 9b014798 2b012001 2002d008 d0052b02
I/DEBUG   (17146): 81d03650 425a3b03 2003415a 40184253 bd00b003
I/DEBUG   (17146): 81d03660 000051dc 00000194 4a2fb570 447a4c2f
I/DEBUG   (17146):
I/DEBUG   (17146): stack:
I/DEBUG   (17146):     487f8af8  43a4ffac
I/DEBUG   (17146):     487f8afc  afd0be39  /system/lib/libc.so
I/DEBUG   (17146):     487f8b00  00000000
I/DEBUG   (17146):     487f8b04  b0004a8c  /system/bin/linker
I/DEBUG   (17146):     487f8b08  b00170f4
I/DEBUG   (17146):     487f8b0c  81d03629  /data/data/paulscode.android.mupen64p
lus/lib/libmain.so
I/DEBUG   (17146):     487f8b10  0000acac  [heap]
I/DEBUG   (17146):     487f8b14  0026bc10  [heap]
I/DEBUG   (17146):     487f8b18  00000000
I/DEBUG   (17146):     487f8b1c  00000010
I/DEBUG   (17146):     487f8b20  43a4ffac
I/DEBUG   (17146):     487f8b24  00206c10  [heap]
I/DEBUG   (17146):     487f8b28  00000000
I/DEBUG   (17146):     487f8b2c  00000000
I/DEBUG   (17146):     487f8b30  df002777
I/DEBUG   (17146):     487f8b34  e3a070ad
I/DEBUG   (17146): #01 487f8b38  00206c10  [heap]
I/DEBUG   (17146):     487f8b3c  00000000
I/DEBUG   (17146):     487f8b40  0000001c
I/DEBUG   (17146):     487f8b44  aca11038  /system/lib/libdvm.so
I/ActivityManager( 2037): Process com.noshufou.android.su (pid 21747) has died.
D/Zygote  ( 1970): Process 22018 terminated by signal (11)
I/ActivityManager( 2037): Process paulscode.android.mupen64plus (pid 22018) has
died.
I/WindowManager( 2037): WIN DEATH: Window{45e4e120 SurfaceView paused=false}
I/WindowManager( 2037): WIN DEATH: Window{45e4b118 paulscode.android.mupen64plus
/paulscode.android.mupen64plus.SDLActivity paused=false}
I/UsageStats( 2037): Unexpected resume of mobi.SyndicateApps.ICSPlus while alrea
dy resumed in paulscode.android.mupen64plus
I/BootReceiver( 2037): Copying /data/tombstones/tombstone_01 to DropBox (SYSTEM_
TOMBSTONE)
D/dalvikvm( 2037): GC_FOR_MALLOC freed 10985 objects / 805256 bytes in 158ms
W/InputManagerService( 2037): Got RemoteException sending setActive(false) notif
ication to pid 22018 uid 10044
Title: Re: Alpha Testing Underway!
Post by: TFreestone on December 01, 2011, 01:23:05 PM

Tested new core #4 close/resume And not work on Imap (armv6)

Code: [Select]
V/SDLActivity(22018): SDLSurface new instance
D/dalvikvm(22018): GC_FOR_MALLOC freed 7492 objects / 537976 bytes in 56ms
I/global  (22018): Default buffer size used in BufferedReader constructor. It wo
uld be better to be explicit if an 8k-char buffer is required.
I/global  (22018): Default buffer size used in BufferedReader constructor. It wo
uld be better to be explicit if an 8k-char buffer is required.
V/GamePad (22018): Mupen64Plus AE Analog Touch
V/GamePad (22018):     ver 1.0
V/GamePad (22018):     Analog gamepad with a clean, intuitive layout
V/GamePad (22018):     Author: roymustang16 and Paul Lamb
D/dalvikvm(22018): GC_FOR_MALLOC freed 1183 objects / 271936 bytes in 49ms
D/dalvikvm(22018): GC_EXTERNAL_ALLOC freed 22 objects / 17872 bytes in 46ms
D/dalvikvm(22018): GC_EXTERNAL_ALLOC freed 167 objects / 337968 bytes in 47ms
V/SDLActivity(22018): SDLSurface created
V/SDLActivity(22018): SDLSurface changed
V/SDL     (22018): pixel format OPAQUE (using SDL_PIXELFORMAT_RGB565)
V/SDLActivity(22018): Starting new SDLMain() thread
I/SDL     (22018): SDL_Android_Init()
V/front_end(22018):  __  __                         __   _  _   ____  _

V/front_end(22018): |  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ __
_
V/front_end(22018): | |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / _
_|
V/front_end(22018): | |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__
 \
V/front_end(22018): |_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|__
_/
V/front_end(22018):              |_|         http://code.google.com/p/mupen64plu
s/
V/front_end(22018): Mupen64Plus Console User-Interface Version 1.99.4
V/front_end(22018):
V/core_interface(22018): UI-console: attached to core library 'Mupen64Plus Core'
 version 1.99.4
V/core_interface(22018):             Includes support for Dynamic Recompiler.
I/DEBUG   (17146): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *
**
I/DEBUG   (17146): Build fingerprint: 'NBPC/AIRIS/AIRIS/:2.2/FRF85B/eng.liuqi.20
110719.192824:user/test-keys'
I/DEBUG   (17146): pid: 22018, tid: 22036  >>> paulscode.android.mupen64plus <<<

I/DEBUG   (17146): signal 11 (SIGSEGV), fault addr 00000000
I/DEBUG   (17146):  r0 00000009  r1 00000001  r2 487f8b3c  r3 00000000
I/DEBUG   (17146):  r4 487f8b68  r5 00000004  r6 43e1338a  r7 43a4ffc8
I/DEBUG   (17146):  r8 487f8b48  r9 43a4ffc0  10 43a4ffac  fp 487f8ed8
I/DEBUG   (17146):  ip 81d03629  sp 487f8b38  lr 81d03643  pc 00000000  cpsr 200
00010
I/DEBUG   (17146):          #00  pc 00000000
I/DEBUG   (17146):          #01  pc 00003640  /data/data/paulscode.android.mupen
64plus/lib/libmain.so
I/DEBUG   (17146):          #02  pc 00011034  /system/lib/libdvm.so
I/DEBUG   (17146):          #03  pc 0003e8cc  /system/lib/libdvm.so
I/DEBUG   (17146):          #04  pc 00043de0  /system/lib/libdvm.so
I/DEBUG   (17146):          #05  pc 00015fa8  /system/lib/libdvm.so
I/DEBUG   (17146):          #06  pc 0001c9c0  /system/lib/libdvm.so
I/DEBUG   (17146):          #07  pc 0001b864  /system/lib/libdvm.so
I/DEBUG   (17146):          #08  pc 00054b8a  /system/lib/libdvm.so
I/DEBUG   (17146):          #09  pc 00054da2  /system/lib/libdvm.so
I/DEBUG   (17146):          #10  pc 00048d7e  /system/lib/libdvm.so
I/DEBUG   (17146):          #11  pc 00011198  /system/lib/libc.so
I/DEBUG   (17146):          #12  pc 00010c7c  /system/lib/libc.so
I/DEBUG   (17146):
I/DEBUG   (17146): code around pc:
I/DEBUG   (17146):
I/DEBUG   (17146): code around lr:
I/DEBUG   (17146): 81d03620 00005212 00000194 b083b500 4b0c2200
I/DEBUG   (17146): 81d03630 4a0c9201 2009447b 2101589b 681baa01
I/DEBUG   (17146): 81d03640 9b014798 2b012001 2002d008 d0052b02
I/DEBUG   (17146): 81d03650 425a3b03 2003415a 40184253 bd00b003
I/DEBUG   (17146): 81d03660 000051dc 00000194 4a2fb570 447a4c2f
I/DEBUG   (17146):
I/DEBUG   (17146): stack:
I/DEBUG   (17146):     487f8af8  43a4ffac
I/DEBUG   (17146):     487f8afc  afd0be39  /system/lib/libc.so
I/DEBUG   (17146):     487f8b00  00000000
I/DEBUG   (17146):     487f8b04  b0004a8c  /system/bin/linker
I/DEBUG   (17146):     487f8b08  b00170f4
I/DEBUG   (17146):     487f8b0c  81d03629  /data/data/paulscode.android.mupen64p
lus/lib/libmain.so
I/DEBUG   (17146):     487f8b10  0000acac  [heap]
I/DEBUG   (17146):     487f8b14  0026bc10  [heap]
I/DEBUG   (17146):     487f8b18  00000000
I/DEBUG   (17146):     487f8b1c  00000010
I/DEBUG   (17146):     487f8b20  43a4ffac
I/DEBUG   (17146):     487f8b24  00206c10  [heap]
I/DEBUG   (17146):     487f8b28  00000000
I/DEBUG   (17146):     487f8b2c  00000000
I/DEBUG   (17146):     487f8b30  df002777
I/DEBUG   (17146):     487f8b34  e3a070ad
I/DEBUG   (17146): #01 487f8b38  00206c10  [heap]
I/DEBUG   (17146):     487f8b3c  00000000
I/DEBUG   (17146):     487f8b40  0000001c
I/DEBUG   (17146):     487f8b44  aca11038  /system/lib/libdvm.so
I/ActivityManager( 2037): Process com.noshufou.android.su (pid 21747) has died.
D/Zygote  ( 1970): Process 22018 terminated by signal (11)
I/ActivityManager( 2037): Process paulscode.android.mupen64plus (pid 22018) has
died.
I/WindowManager( 2037): WIN DEATH: Window{45e4e120 SurfaceView paused=false}
I/WindowManager( 2037): WIN DEATH: Window{45e4b118 paulscode.android.mupen64plus
/paulscode.android.mupen64plus.SDLActivity paused=false}
I/UsageStats( 2037): Unexpected resume of mobi.SyndicateApps.ICSPlus while alrea
dy resumed in paulscode.android.mupen64plus
I/BootReceiver( 2037): Copying /data/tombstones/tombstone_01 to DropBox (SYSTEM_
TOMBSTONE)
D/dalvikvm( 2037): GC_FOR_MALLOC freed 10985 objects / 805256 bytes in 158ms
W/InputManagerService( 2037): Got RemoteException sending setActive(false) notif
ication to pid 22018 uid 10044
you were supposed to use the original build without resume because of the new bugs that added..
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 01, 2011, 02:41:40 PM
Xperia64,

Which libcore are you using? is it ARM7 or Pre-ARM7?

All the best,

NSCXP2005
im armv7 on xperia play
Title: Re: Alpha Testing Underway!
Post by: Paul on December 01, 2011, 04:05:22 PM
you were supposed to use the original build without resume because of the new bugs that added..

 ;) Case in point:
Code: [Select]
I/DEBUG   (17146): stack:
I/DEBUG   (17146):     487f8af8  43a4ffac
I/DEBUG   (17146):     487f8afc  afd0be39  /system/lib/libc.so
I/DEBUG   (17146):     487f8b00  00000000
I/DEBUG   (17146):     487f8b04  b0004a8c  /system/bin/linker
I/DEBUG   (17146):     487f8b08  b00170f4
I/DEBUG   (17146):     487f8b0c  81d03629  /data/data/paulscode.android.mupen64plus/lib/libmain.so
(it crashed in the front end, not the core)

Also, could you post the memory maps after running the test with the last official build?  They will show whether this optimization is possible on your device.  They should be located at [sdcard]/app-data/paulscode.android.mupen64plus/DEBUG_PluginTestA_memoryMaps.txt  Also, don't forget to change the permissions of libcore.so to executable after replacing it (that is likely what caused your crash in the front-end, which is where the .so file is executed from - further supported by the fact that the stack mentions "/system/bin/linker").
Title: Re: Alpha Testing Underway!
Post by: Paul on December 01, 2011, 06:54:57 PM
Ok, I think I know what the problem could be (I hope I'm wrong, though, because I don't see any way around it).  Please provide the logcat output for this version, as well as the memory maps after running it:

Core w/ RDRAM at Native Address, verbose (#5) (http://www.paulscode.com/source/Mupen64Plus-AE/01DEC2011/mupen64plus-core-noTLB.zip)
Title: Re: Alpha Testing Underway!
Post by: MaXiMu on December 01, 2011, 07:43:33 PM

haha I test on build without resume is working ok No crash thanks all  ;D
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 01, 2011, 09:17:03 PM
Again here
Title: Re: Alpha Testing Underway!
Post by: Paul on December 01, 2011, 09:29:27 PM
Ok, one more (same link, since the change is minor).  Also, please post the memory maps file after running the test.
Title: Re: Alpha Testing Underway!
Post by: nscxp2005 on December 02, 2011, 05:37:02 AM
Here's mine Paul.

Title: Re: Alpha Testing Underway!
Post by: Paul on December 02, 2011, 01:20:20 PM
Oh, that's good news!  Means I was wrong about what was causing the problem.  Now I just have to figure out why the mmap is failing.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 02, 2011, 01:48:20 PM
Here's mine just in case
Title: Re: Alpha Testing Underway!
Post by: Paul on December 02, 2011, 08:42:08 PM
Ok, this version should print out an error code when the mmap fails.  Hopefully it will be something useful that will indicate what I need to change:

Core w/ RDRAM at Native Address, verbose (#6) (http://www.paulscode.com/source/Mupen64Plus-AE/02DEC2011/mupen64plus-core-noTLB.zip)
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 02, 2011, 08:50:40 PM
On it
Title: Re: Alpha Testing Underway!
Post by: Paul on December 02, 2011, 09:23:38 PM
It gave error code 12 (ENOMEM).  According to the documentation, this means "MAP_FIXED was specified, and the range [addr,addr+len) exceeds that allowed for the address space of a process".  I guess that explains why the XPeria Play doesn't have any system libraries loaded there..  I'm wondering if this optimization would work on any Android device.  :(  Oh, well.. back to working on the GUI, I suppose.
Title: Re: Alpha Testing Underway!
Post by: Mats on December 03, 2011, 09:26:00 AM
It gave error code 12 (ENOMEM).  According to the documentation, this means "MAP_FIXED was specified, and the range [addr,addr+len) exceeds that allowed for the address space of a process".  I guess that explains why the XPeria Play doesn't have any system libraries loaded there..  I'm wondering if this optimization would work on any Android device.  :(  Oh, well.. back to working on the GUI, I suppose.
how does u write a gui ?
Title: Re: Alpha Testing Underway!
Post by: Paul on December 03, 2011, 09:56:57 AM
It's written in Java.  The API is unique for Android though (very different than the standard Swing API in Sun/Oracle Java)
Title: Re: Alpha Testing Underway!
Post by: Mats on December 03, 2011, 12:45:29 PM
It's written in Java.  The API is unique for Android though (very different than the standard Swing API in Sun/Oracle Java)
thanks, in the first build with gui would you change the video plugin ??
Title: Re: Alpha Testing Underway!
Post by: Paul on December 03, 2011, 02:26:20 PM
Yes
Title: Re: Alpha Testing Underway!
Post by: Paul on December 03, 2011, 04:32:52 PM
I just wanted to let everyone know, the app data is changing quite a bit in the upcomming version.  The old app data can be found here (http://www.paulscode.com/downloads/mupen64plus_data_old.zip).

Anybody new who hasn't tested the app yet, please wait until the next version comes out (unless you are comfortable with manually changing the app data).  The current official build in the first post will not work without the old app data!  I'll try and get everything finished sometime tomorrow if humanly possible.
Title: Re: Alpha Testing Underway!
Post by: SpawnHyuuga on December 03, 2011, 05:12:47 PM
I'm quite excited Paul. I hope to see that this will work great for all of us. :D
Title: Re: Alpha Testing Underway!
Post by: FunkyTiemy on December 03, 2011, 05:56:58 PM
Hey Paul

Please make a mupen64 version that supports Gles1. For low devices
And set graphics at low or something. For low end devices too :P
So i can play it on HTC Wildfire
I hope you can do this.
Oh yeah keep up the good work.
And if mupen was in android market i want it even when i have to pay for it :P

so greets FunkyTiemy
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 03, 2011, 06:34:59 PM
I am trying to create an app that automatically deletes the app-data but I really cant figure out what's wrong with my code...

I made it so it creates a list of all the drive letters being used and the user then chooses which ever one is their device. Even is I hard code the directory path it still doesn't work.

Oh well its not like its complicated to delete the file manually anyway haha :P


heres my source code:

Code: [Select]
Option Strict On
Public Class Form1
   
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load


        Dim driveNames As New List(Of String)

        For Each drv As System.IO.DriveInfo In System.IO.DriveInfo.GetDrives
            If drv.DriveType = IO.DriveType.Removable AndAlso drv.IsReady Then
                Dim drvLetter As String = drv.Name

                DrvLtrLstBx.Items.Add(drv.Name)
            End If

        Next

    End Sub

    Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles DriveLtrBtn.Click
        DrvTexBx.Text = DrvLtrLstBx.Text
    End Sub

    Private Sub ListBox1_SelectedIndexChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles DrvLtrLstBx.SelectedIndexChanged

    End Sub

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles RfrshBtn.Click
        DrvLtrLstBx.Items.Clear()

        For Each drv As System.IO.DriveInfo In System.IO.DriveInfo.GetDrives
            If drv.DriveType = IO.DriveType.Removable AndAlso drv.IsReady Then
                Dim drvLetter As String = drv.Name

                DrvLtrLstBx.Items.Add(drv.Name)
            End If

        Next
    End Sub

    Private Sub Button4_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles DltBtn.Click
        If Dir(DrvTexBx.Text + "app-data") <> "" Then
            My.Computer.FileSystem.DeleteDirectory(DrvTexBx.Text + "app-data", _
FileIO.DeleteDirectoryOption.ThrowIfDirectoryNonEmpty)
            MsgBox("app-data deleted")
        Else
            MsgBox("app-data not found")
        End If
    End Sub
End Class

EDIT: I got it to work in the end I just changed

Code: [Select]
Private Sub Button4_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles DltBtn.Click
        If Dir(DrvTexBx.Text + "app-data") <> "" Then
            My.Computer.FileSystem.DeleteDirectory(DrvTexBx.Text + "app-data", _
FileIO.DeleteDirectoryOption.ThrowIfDirectoryNonEmpty)
            MsgBox("app-data deleted")
        Else
            MsgBox("app-data not found")
        End If
    End Sub

To...

Code: [Select]
Private Sub Button4_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles DltBtn.Click
        If Dir(DrvTexBx.Text + "app-data\paulscode.android.mupen64plus") = "" Then
            My.Computer.FileSystem.DeleteDirectory(DrvTexBx.Text + "app-data\paulscode.android.mupen64plus", _
FileIO.DeleteDirectoryOption.DeleteAllContents)
            MsgBox("app-data deleted")
        Else
            MsgBox("app-data not found")
        End If
    End Sub

I wont post the exe file without pauls permission but anyone can build this themselfs.... them again if somebody knows how to compile the code then they dont really need this app. :P
Title: Re: Alpha Testing Underway!
Post by: FunkyTiemy on December 03, 2011, 06:41:16 PM
Do i have to put that code somewhere  :-X?
Srry iam dorky with emulators like this :-X
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 03, 2011, 06:43:54 PM
Do i have to put that code somewhere  :-X?
Srry iam dorky with emulators like this :-X

No no thats just the code for the program I was trying to make which automatically deletes the app-data. The codes only there if people are interested in it.

Nothing to do with the emulator :P
Title: Re: Alpha Testing Underway!
Post by: FunkyTiemy on December 03, 2011, 06:54:17 PM
Oh srry

But does anybody know how to use it on Wildfire it doesn't
work idk why

Please help
Title: Re: Alpha Testing Underway!
Post by: Paul on December 03, 2011, 07:20:58 PM
But does anybody know how to use it on Wildfire it doesn't work idk why
Hello again Tiemen, welcome to the forums.  I believe I mentioned in one of my earlier emails that the HTC Wildfire does not have a GPU and thus does not support GLES2.  Currently both video plug-ins require GLES2, so the emulator will not work on your phone until I create a GLES1 video plug-in.

Please make a mupen64 version that supports Gles1.
It is pretty high on my priority list (there are a few other things I want to tackle first after I finish the GUI).
Title: Re: Alpha Testing Underway!
Post by: Kris on December 03, 2011, 10:39:39 PM
I posted an updated version of my rice port here (https://www.box.com/s/nt4urp660smfgpf03i88). It has some fixes with 2d elements but there are still issues. I finally located what was messing the normals up a few weeks ago but I only just released a version of my emu with rice support. The problem was x86 and arm have different defaults for using signed and unsigned chars :o this affected NormalStruct in typedefs.h. The easiest fix is to compile with -fsigned-char
Title: Re: Alpha Testing Underway!
Post by: Paul on December 03, 2011, 10:45:40 PM
Roymustang16, I've been meaning to ask if you'd like to design a FPS indicator that matches your virtual gamepad skin.  I'd just need a background image and images for digits 0-9 (.png format).  I've put together a basic one that I can use, but I'm not as good an artist.  I can post a screenshot if you want to see how mine looks.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 03, 2011, 10:48:02 PM
I posted an updated version of my rice port here (https://www.box.com/s/nt4urp660smfgpf03i88). It has some fixes with 2d elements but there are still issues. I finally located what was messing the normals up a few weeks ago but I only just released a version of my emu with rice support. The problem was x86 and arm have different defaults for using signed and unsigned chars :o this affected NormalStruct in typedefs.h. The easiest fix is to compile with -fsigned-char
Hey thanks again!  I'll incorporate the updates tomorrow.
Title: Re: Alpha Testing Underway!
Post by: roymustang16 on December 04, 2011, 03:01:45 AM
Roymustang16, I've been meaning to ask if you'd like to design a FPS indicator that matches your virtual gamepad skin.  I'd just need a background image and images for digits 0-9 (.png format).  I've put together a basic one that I can use, but I'm not as good an artist.  I can post a screenshot if you want to see how mine looks.

Yes a screenshot could help me to see what you would like.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 06:20:26 AM
This is what I came up with.  It's ok, but it almost seems like another controller button:

(http://www.paulscode.com/source/Mupen64Plus-AE/screenshots/04DEC2011/MarioFPS2.png)

If you decide to come up with a different one, feel free to change the size or rearrange the layout as you like.
Title: Re: Alpha Testing Underway!
Post by: roymustang16 on December 04, 2011, 07:08:18 AM
Here is the zip file with digits.png and fps_background.png
(http://img51.imageshack.us/img51/9087/mariofps2.png)
If you have any remark don't hesitate, and just one thing before the new release, the A/B button should be just below (right bottom) the C-Button to be more adapted to the hand and like this the thumb will hide less the game.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 07:20:18 AM
Thanks.  I can't remember why the buttons were moved - maybe they interfered on some resolutions (sadly I've temporarily removed the forum archives, so I can't go back and see).  Does any one else on here remember?  I can move them back if there wasn't a problem.
Title: Re: Alpha Testing Underway!
Post by: roymustang16 on December 04, 2011, 07:25:31 AM
I think they were always like that, even on the first mockup i made
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 08:26:23 AM
OK, here's a screenshot after the changes.  Let me know if the layout is ok.  I moved the A/B buttons to 90% X, because 100% looked a little crammed.

(http://www.paulscode.com/source/Mupen64Plus-AE/screenshots/04DEC2011/MarioFPS3.png)
Title: Re: Alpha Testing Underway!
Post by: roymustang16 on December 04, 2011, 08:31:13 AM
It's perfect, but the fps counter doesn't seem to be exactly in the middle of the screen.
Anyway, really impatient to try the next version with GUI.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 08:35:34 AM
The reason the FPS isn't exactly centered is the way I wrote the code - it centers the numbers on the FPS background image (so I extended some transparent space on the left side of the background image so the numbers show up in the correct place).  If it's really noticeable, I can tweak the X percentage so it looks centered (will only work for a particular aspect ratio of course).

--EDIT-- I'll just add a couple more parameters (numx and numy) which specify a percentage on the background image where the numbers should be centered.  This will solve the centering issue.
Title: Re: Alpha Testing Underway!
Post by: roymustang16 on December 04, 2011, 08:56:35 AM
It's only noticeable because the start button is centered, but seriously it's doesn't matter.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 09:28:41 AM
No worries, it was an easy fix.  Here's how it looks now with the new number offset parameters:

(http://www.paulscode.com/source/Mupen64Plus-AE/screenshots/04DEC2011/MarioFPS5.png)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 10:00:52 AM
Kris, I've been meaning to ask you, do you have the source for rsp-no-sound posted somewhere, or are you keeping that library closed at the moment?
Title: Re: Alpha Testing Underway!
Post by: Kris on December 04, 2011, 10:33:53 AM
For the no-sound I just return early from a method, I just compiled it and changed it back. I checked to see if I had the change in source control but it isn't there. If I remember correctly I put either 'return 0;' or 'return -1;' at the beginning of audio_ucode in main.c:69. I originally named it libmupen64plus-rsp-hle-no-sound but that conflicted and caused the wrong library to be loaded.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 11:05:19 AM
Gotcha, thanks.  I haven't really looked at the code for the rsp plug-in yet (it compiled "out-of-the-box"), so I wasn't sure what all would be involved.  Sounds simple enough.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 11:12:31 AM
I finished adding your updates to the rice plug-in.  It's looking much better  :)
Title: Re: Alpha Testing Underway!
Post by: kane on December 04, 2011, 11:52:58 AM
hello guys,

i just found this site and i see you are working on this for a long time. i have a samsung galaxy ace and i want to play nintendo 64 games, n64oid doesnt work :( how far are you in ? is there already a way to download this? i?m searching for monthes and i think i finally found something here. You would make me very happy with a download link, see you soon :)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 11:56:47 AM
There is a link in the initial post of this thread, however it will not work at the moment unless you manually replace the app-data after running the app the first time.  I'm in the middle of a fairly major update, so stay tuned for the next official build (hopefully today if I can finish everything)
Title: Re: Alpha Testing Underway!
Post by: kane on December 04, 2011, 11:59:35 AM
wow what a fast answere, didnt expect this. thank you very much. I will wait then, please tell me when your finished. I dont even have a idea about all this, so i cant do nothing by my own :). you would make me so happy if this would work on my ace.
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on December 04, 2011, 12:22:09 PM
[ot] zodttd tweets, that he'll release a new update for n64iphone in a few days. [/ot]

Maybe he has new sources ideas ?  ;D
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 12:26:09 PM
Quick update on where I'm at (for anyone interested):

I've nearly finished implementing the new virtual gamepad syntax.  The main difference, as you can see in my earlier screenshots, is the ability to add an FPS indicator (thanks, roymustang16 for the artwork - it looks great!)  I still need to add the "SDL button" option to the syntax (this will be finished shortly).  I'm not planning to add any of these to the default layouts, I just want them to be an option (to make things like "fast forward", "reset", etc possible from the virtual gamepad).

I fixed all of the bugs (that I'm aware of) with the virtual gamepad.  There is now no difference in speed between the "touch" version and the one with the stick (the problem was related to thread synchronization).  I'll still leave the "touch" skins as an option in case there is still a performance difference on slower devices.  I also added some new "tiny" layouts for super-small screens.

I've incorporated Kris' updates to the gles2rice video plug-in.  There are still some issues, including flickering shadows and stars in Mario64, inaccurate textures (grass inside the castle in Mario64), slow frame-rate (around 17-19 FPS in Mario64), and some problems with the 2D images ("Press Start" is missing in Mario64).  Overall, though, it is looking very good (Conkers is rendered nearly perfect - just a few sorting errors).

I've compiled Kris' no-sound RSP plug-in idea.  It provides a noticeable improvement to higher-end games (Zelda64 runs full-speed in the forest with all the flying fairies even without overclocking, Conkers is more playable, etc.)

I'm still having some issues with the menu switching logic (resulting in occasional crashes or ending up in the wrong area).  This is the main thing I need to sort out before I post the next update.  There are also two or three options in the menu that don't function yet (I mentioned them earlier in this thread).
Title: Re: Alpha Testing Underway!
Post by: kane on December 04, 2011, 12:52:36 PM
do you have any idea when this project will reach perfection? what is left?
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 04, 2011, 12:55:29 PM
Great job on the progress paul :)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 01:15:49 PM
do you have any idea when this project will reach perfection? what is left?

I don't think there is really such a thing as a perfect N64 emulator, at least not until computers about 3 or 4 times faster than they are now so they can handle emulating the hardware at the lowest level (HLE will probably never be perfect).  That being said, I'd bet in a couple years of optimizations and bug-fixes, this project (and its branches) should be running on-par with any other N64 emulators out there.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 04, 2011, 01:21:54 PM
One thing i would like is the "T1 or T0 framebuffer emulation" or whatever it is so that the pause menu of zelda64 will actually show link instead of the random textures =/
Title: Re: Alpha Testing Underway!
Post by: TFreestone on December 04, 2011, 01:36:05 PM
so how will this update be distributed? as a new apk or with a collection of files that we replace the old ones with?
sorry if thats a dumb question. all this appdata talk has got me confused.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 01:50:07 PM
so how will this update be distributed? as a new apk or with a collection of files that we replace the old ones with?
sorry if thats a dumb question. all this appdata talk has got me confused.
It will be distributed the same way as usual, however those of you who have a previous version installed will have to delete the app-data/paulscode.android.mupen64plus folder from your sdcard so the new app-data will be downloaded.  One of the things I need to add to the GUI is a button that refreshes the app-data for you (I keep remembering all these little things - that's why I'm so bad at predicting how long things take).

One thing i would like is the "T1 or T0 framebuffer emulation" or whatever it is so that the pause menu of zelda64 will actually show link instead of the random textures =/
That's on my to-do list.  I'm going to try and get ahold of Jabo at some point to see if he will release the relevant pieces of his source code, or at least give me a few pointers.  Hopefully he won't see me as competition since his plug-in is for DirectX (although realistically as soon as this goes open-source I'd be surprised if every N64 emulator out there didn't immediately implement it as well)
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 04, 2011, 02:17:25 PM
Ive added a bit more to my app that deletes the app-data, soon it will automatically install the mupen64plus-ae apk via adb. I only wish I had made this back in the heavy alpha testing phase as it would have made installing the test builds alot faster. :P
Title: Re: Alpha Testing Underway!
Post by: TFreestone on December 04, 2011, 02:40:51 PM
as far as contacting jabo for to release his source i hope it goes well :) his is the best plugin as far as emulating the original n64 graphics. Although he's behind in the retexture field. i also heard someone mention zodttd :) i saw those tweets too and i think its very likely he will release his source code since he's been given a lot of crap about it.. Good work to everyone who has helped program this thing, i for one am enjoying the fruits of your labor ;)
Title: Re: Alpha Testing Underway!
Post by: FunkyTiemy on December 04, 2011, 03:00:41 PM
Paul,

Can you please tell a date when it supports gles1
I'm a little nervous because i really like to play n64
I have the real console too and its cool and the only 3d console
one that is emulated on mobile with a good speed
and i wanna play it in the train, plane , at school , etc.
But my mobile doesn't have gles2
So pppllleeeaaassseee fix this  ;D ;D ;D

Thanks a lot

Oh and another strange thing if i push back, menu, search or home button
A little box comes at my screen with the text : "scancode ..." (... is a number because when i press different buttons there pops out different numbers)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 03:12:00 PM
Can you please tell a date when it supports gles1
Well, I am very bad at estimating how long things take, but if I develop it myself, don't expect it to be usable earlier than 4-6 months from now, and probably a year or more before it runs at a fast enough speed for games to be really playable on low-end devices.  This component will not be trivial (GLES1, despite the similar name, is completely different than either GLES2 or vanilla OpenGL), and I'm not the best GL developer out there to begin with (it will definitely be a learning experience).  Like I said, it is high on my priority list, but it isn't something that I'll be able to complete as quickly as some other things, and obviously not something I will be able to dedicate 100% of my time to (or nothing else will get done).
Title: Re: Alpha Testing Underway!
Post by: FunkyTiemy on December 04, 2011, 03:24:51 PM
w00t :o

A half year i can't wait that long :-\
So maybe im gonna buy a new device
And cant you just create it with gles1 and running a bit slow i dont care
if its slow i can deal with it
I just wanna play it :-X
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 03:32:19 PM
You could always ask Yongzh to write one for N64oid, since he has great experience writing a brand-new video plug-in from scratch, and is very concerned about supporting folks with older devices and the open-source community  :P
Title: Re: Alpha Testing Underway!
Post by: FunkyTiemy on December 04, 2011, 03:44:49 PM
Gimme his mail adress pleaseeee
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 03:47:44 PM
freeman.yong@gmail.com

Be sure to mention that I sent ya, haha!
Title: Re: Alpha Testing Underway!
Post by: FunkyTiemy on December 04, 2011, 04:09:51 PM
But Paul do you know what my problem is with n64oid...
It even don't installs maybe you should try it on your xperia play
Maybe it works your phone (because on all my friends phones it dont works too : HTC Desire HD / Samsung Galaxy Mini / Samsung Galaxy Ace / Samsung Galaxy Apollo / Samsung Galaxy Y.)
Its kinda strange even the emu BIT64 doesn't install on that phones
Title: Re: Alpha Testing Underway!
Post by: TFreestone on December 04, 2011, 04:57:02 PM
But Paul do you know what my problem is with n64oid...
It even don't installs maybe you should try it on your xperia play
Maybe it works your phone (because on all my friends phones it dont works too : HTC Desire HD / Samsung Galaxy Mini / Samsung Galaxy Ace / Samsung Galaxy Apollo / Samsung Galaxy Y.)
Its kinda strange even the emu BIT64 doesn't install on that phones
bit64 and n64oid use armv7 which those phones dont have. You need like a samsung gs or higher for those. As far as contacting yongz for to support your device, good luck haha ;p if you want to emulate n64 i suggest investing in better hardware :) eg galaxy s or higher although i see one of your friends had a desire hd, so maybe there is a problem with htc and n64 though i doubt it.. But as for the wildfire you can forget it, not even worth it imo.. Small screen and slow
Title: Re: Alpha Testing Underway!
Post by: TFreestone on December 04, 2011, 05:01:53 PM
You could always ask Yongzh to write one for N64oid, since he has great experience writing a brand-new video plug-in from scratch, and is very concerned about supporting folks with older devices and the open-source community  :P
oh the beauty of irony ;) or was that sarcasm heheh
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 05:12:33 PM
But Paul do you know what my problem is with n64oid...
It even don't installs maybe you should try it on your xperia play
Maybe it works your phone (because on all my friends phones it dont works too : HTC Desire HD / Samsung Galaxy Mini / Samsung Galaxy Ace / Samsung Galaxy Apollo / Samsung Galaxy Y.)
Its kinda strange even the emu BIT64 doesn't install on that phones

I don't actually own an XPeria Play (I'm considering getting one, but my phone is a Droid X).  Obviously I was joking about Yongzh supporting users with older devices (and the other things).  N64oid will not work on pre-ARM7 devices, and there's probably a snowball's chance of convincing him to write a GLES1 video plug-in.

Bit64, N64 Arcade, and a couple others that used to be on the Android market (I forgot the names) are all hack-and-pack rip-offs of early versions of N64oid, probably using tools like dex2jar and jd-gui to decompile the Java source, altering, recompiling, and repackaging with the original .so libraries into a new .apk.  That's why they all have the same features and limitations (and look nearly identical as well).
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 05:19:28 PM
I'm going to call it a day (head is swimming from staring at the screen).  Sorry to everyone waiting for the update - it will be a little longer.  I'll work on it some more tomorrow evening after work.
Title: Re: Alpha Testing Underway!
Post by: tgwaste on December 04, 2011, 06:42:30 PM

mupen64 + http://gametelcontroller.com/ = winning

Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 04, 2011, 07:06:46 PM

mupen64 + http://gametelcontroller.com/ = winning

For N64 games you might want to look at the iControl pad, The gametel doesnt really have enough buttons although it certainly looks a lot better than icontrolpad.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 07:19:20 PM
Interesting.  Is that a touchpad in the bottom-center, or just an indentation in the plastic?
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 04, 2011, 07:34:48 PM
paul: http://www.gametel.se/index.php/explore/specification
Title: Re: Alpha Testing Underway!
Post by: Paul on December 04, 2011, 07:56:42 PM
Yeh, didn't think it was a touchpad.  Well, at least the emulator should support that out-of-the-box assuming the Android app emulates it as a keyboard (presumably it does)
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on December 05, 2011, 12:47:11 AM

mupen64 + http://gametelcontroller.com/ = winning
we need one with at least 1 analog stick, btw why is war?ow in the xperia's screen in the image?(it's a fps)
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 05, 2011, 01:59:59 AM
Like I said before, if you wanna play games on your android phone and you cant afford an xperia play the next best thing is http://www.icontrolpad.com/ (http://www.icontrolpad.com/)

Its got two analog sticks too which is great for n64 and PS1 games, I just wish it looked as good as that other controller.
Title: Re: Alpha Testing Underway!
Post by: onthebridge on December 05, 2011, 02:12:26 AM
The real winning is mupen64 + Android handheld console  ;D

You can see one here: http://www.youtube.com/watch?v=00C6RT-HawU
Title: Re: Alpha Testing Underway!
Post by: kane on December 05, 2011, 07:02:08 AM
well guys back to the topic before. I installed the app but i had some problems, the first great thing is that the game started (super mario 64) but the touchscreen didnt react, there were no buttons expect the circle on the left, but i wasnt able to use it. the music was very laggy, which is not a problem for me, i dont care about the music as long as i can play without laggs. i have the samsung galaxy ace and i try to find another emulator to play n 64 games on my ace, because n64oid doesnt work. i can install it, but everytime i open a rom it turns into a black screen and the app gets closed. Is there any other emulator so far, which makes it possible to play n64 games on my ace?
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 05, 2011, 01:46:04 PM
Like I said before, if you wanna play games on your android phone and you cant afford an xperia play the next best thing is http://www.icontrolpad.com/ (http://www.icontrolpad.com/)

Its got two analog sticks too which is great for n64 and PS1 games, I just wish it looked as good as that other controller.
i actually have an icontrolpad that i won online ;D (srysly i didn't pay a cent)
Title: Re: Alpha Testing Underway!
Post by: kane on December 05, 2011, 02:18:26 PM
but why should i buy that if i cant even get the game started? if i really find a working emulator for my galaxy ace, i believe i will buy one.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 05, 2011, 04:11:13 PM
well guys back to the topic before. I installed the app but i had some problems, the first great thing is that the game started (super mario 64) but the touchscreen didnt react, there were no buttons expect the circle on the left, but i wasnt able to use it.

The emulator should run fine on the Ace (laggy without overclocking, since it is an ARM6 device).  The problem you are having is that, like I said before, the app will not work at the moment unless you manually replace the app-data with the old version (I am in the middle of a major update, and the virtual gamepad is one of the things that has changed significantly).  If you want to try the emulator now, the old app-data is located here (http://www.paulscode.com/downloads/mupen64plus_data_old.zip).  Unzip it and replace the contents of [sdcard]/app-data/paulscode.android.mupen64plus/  Otherwise, you'll have to hold off until I release the next version.  Sorry for the inconvenience (I was hoping to finish the updates yesterday, but I didn't get everything done).
Title: Re: Alpha Testing Underway!
Post by: Chaim on December 05, 2011, 07:02:07 PM
No problem for this  ;D.Thanks for everything, you are a very good dev ;).We will wait two years if necessary :o.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 05, 2011, 08:01:26 PM
Finished implementing the "SDL button" concept for the virtual gamepad (it took a little longer to debug than I anticipated).  The syntax works like this:

In the [MASK_COLOR] section, SDL scancodes are associated with mask colors similar to the way N64 buttons are associated with mask color codes, except the actual scancode is also written in the definition.  The following example entry would associate the mask color 3840560 with SDL scancode 102:
Code: [Select]
Scancode_102=3840560
Then the button itself is defined similar to the way N64 buttons are defined, except info must have one of the scancodes that was listed in the above [MASK_COLOR] section.  So for example, if our button image was called "FFWD.png", the mask color image would be called "FFWD.bmp", and the entry would look something like this:
Code: [Select]
[FFWD]
info=Scancode_102
x=0
y=25
Title: Re: Alpha Testing Underway!
Post by: kane on December 06, 2011, 06:54:22 AM
well ok, i tried it but it didnt work for any reason, i think i?m just anable in these themes. I have to wait for the next update, because i can?t do it alone. Hope this wont take to much time, but it doesnt matter, i have to wait anyway.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 06, 2011, 07:15:44 AM
It will be done soon.  I expect to post some tests this week, and have the official build ready by this weekend.  Could be sooner, depending on how much time I have in the evenings to work on it.  I have a 2 year-old son who likes to play Mario on my phone, and he doesn't really understand when I tell him "Daddy needs to use the phone for a while"  ;D
Title: Re: Alpha Testing Underway!
Post by: kane on December 06, 2011, 09:02:52 AM
it would be great if you could finish it this week. But this is not the end for me, i need a step-to-step explanation, i hope it wont be that complicated. i hope you are strong enough to help a noob to get through ^^
Title: Re: Alpha Testing Underway!
Post by: TFreestone on December 06, 2011, 09:41:58 AM
it would be great if you could finish it this week. But this is not the end for me, i need a step-to-step explanation, i hope it wont be that complicated. i hope you are strong enough to help a noob to get through ^^
the only reason its complicated now is because the current official build doesn't match the updated app data. once paul release the new apk this weekend or whenever it should all just magically work again ;) so just a few more days.
Title: Re: Alpha Testing Underway!
Post by: firstpoke on December 06, 2011, 11:02:09 AM
First, great work! I've tested the last alpha and only some audio laggings and framerate laggings are there. The graphics looks cool! (tested with: Acer Picasso A500, Android 3.2)

This version didnt run at the first try. I had to add the Downloadfile "mupen64plus_data.zip" to the "assets" folder, and after "Home" to add to the function "onUserLeaveHint()" this:

stopEmulator();
nativeQuit();
 

Joystick and Analog-Key Events:

It would be nice, if you integarte my analog-key script from my USBJoystick Center app, for analog joystick moves with normal key mappings (DPAD left = left / strength=0...64, DPAD right = right / strength=0...64, ...):

Code: [Select]
@Override
public boolean onKey(View v, int keyCode, KeyEvent event) {

int[] values = getKeyData(keyCode, event);
textInfo.setText("Keycode: " + values[0] + " | Strength: " + values[1]);
return false;
}


private int[] getKeyData(int keyCode, KeyEvent event) {

int[] values = {0,0};
int action = event.getAction();

if(keyCode > 255) { // * get analog value (0,1,2,3,...,62,63,64) for the keyCode *

if(action == KeyEvent.ACTION_DOWN) {
values[0] = (int)(keyCode/100);
values[1] = (keyCode-(values[0]*100));
}
else if(action == KeyEvent.ACTION_UP) {
values[0] = (int)(keyCode/100);
values[1] = 0;
}
}
else { // * get digital value (0 or 64) for the keyCode *

if(action == KeyEvent.ACTION_DOWN) {
values[0] = keyCode;
values[1] = 64;
}
else if(action == KeyEvent.ACTION_UP) {
values[0] = keyCode;
values[1] = 0;
}
}

return values;
}


You need the "strength" value of the mapped and pressed key to multiply it with the moving object in the game.

I will release a new version of my "USB Joystick Center" tomorrow with the new Analog-Key option, and a "USB Joystick to Analog-Key" Demo too.

Update, here is the video:
http://www.youtube.com/watch?v=OVm5rqc9PlM

greetings
poke
Title: Re: Alpha Testing Underway!
Post by: kane on December 06, 2011, 01:21:52 PM
So there will be a version of this akp. where i dont have to change anything? just install it and i will be able to start playing, just like a normal app ? I get the feeling i?m going on somebodies nerves here, sorry for that.
Title: Re: Alpha Testing Underway!
Post by: Mats on December 06, 2011, 01:49:51 PM
So there will be a version of this akp. where i dont have to change anything? just install it and i will be able to start playing, just like a normal app ? I get the feeling i?m going on somebodies nerves here, sorry for that.
yes install it and let it downloade the app-data and start playing  ;D
Title: Re: Alpha Testing Underway!
Post by: TFreestone on December 06, 2011, 02:02:36 PM
So there will be a version of this akp. where i dont have to change anything? just install it and i will be able to start playing, just like a normal app ? I get the feeling i?m going on somebodies nerves here, sorry for that.
yep should be :) the goal of this app is for it to available on market and that can only happen when its uber user friendly. since its in alpha right now there are a lot of changes happening so we users may have to tweak some things manually. the only reason you are having trouble is because of how the app obtains it's data. correct me if i'm wrong paul, but i think the app connects to a server the first time you run it and it downloads the app data it needs to run. the older builds use the old app data but that has been changed on the server, so when your app on your phone downloads and tries to use it, it doesnt work. so you have to manually downgrade the app data. however once the app is done being updated in full eg in a few days, the app data on the server and the app you download here will match and it all will work automatically.   
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on December 06, 2011, 02:07:55 PM
@ firstpoke

Is there a special reason why your app doesn't support the Samsung Galay 2 USB-Host port and only hc devices ?
I've seen your video from market, but I didn't understand the way how to map the analog sticks.

Ah, and another thing. As the SGS2 and my Android TV box have both USB host and can run the sixaxis maping app, is it possible to make your pairingtool compatible with it ?
Or at least to make an option in your app to map another bt mac adress, so we can pair the sixaxis from a hc tablet for other devices ?

Title: Re: Alpha Testing Underway!
Post by: firstpoke on December 06, 2011, 02:44:22 PM
@scorpio16v

The problem is, that Samsung removed the Android USB Host API from the SGS2. I would if I could support the GoogleTV, but Im on a Mac... and there is no Google Update for that (only Linux). So I have to wait since google released a Mac Plugin.

The MAC-option to write another MAC-Adress is interesting. I think about it. Thanks.

Quote
I've seen your video from market, but I didn't understand the way how to map the analog sticks.

Its easy... tap on a key... move the joystick in one direction, so do it for all 4 directions. Thats it.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 06, 2011, 04:08:12 PM
It would be nice, if you integarte my analog-key script from my USBJoystick Center app, for analog joystick moves with normal key mappings (DPAD left = left / strength=0...64, DPAD right = right / strength=0...64, ...)
Sure, I can add that.  I'll look into it after I get the current update finished and well-tested.  Do you happen to know if those high key-codes will pass through a NativeActivity as well (for the XPeria Play folks)?  Not that they'd actually need another joystick..
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 06, 2011, 05:49:44 PM
It would be nice, if you integarte my analog-key script from my USBJoystick Center app, for analog joystick moves with normal key mappings (DPAD left = left / strength=0...64, DPAD right = right / strength=0...64, ...)
Sure, I can add that.  I'll look into it after I get the current update finished and well-tested.  Do you happen to know if those high key-codes will pass through a NativeActivity as well (for the XPeria Play folks)?  Not that they'd actually need another joystick..
multiplayer lol
Title: Re: Alpha Testing Underway!
Post by: firstpoke on December 06, 2011, 10:26:29 PM
Do you happen to know if those high key-codes will pass through a NativeActivity as well (for the XPeria Play folks)?  Not that they'd actually need another joystick..

Thats not a problem. I've taken a look to the supported key codes in android, and all codes are < 255.
Also the Xperia codes: http://developer.sonyericsson.com/wp/2011/02/13/xperia-play-game-keys/

My C64 Emulator "FrodoC64 USB" (with the physical Keyboard support) uses higher codes > 255 for the Keyboard keys... but this Emu dont need the Analog-Key option, so there is no problem.

greetings
poke
Title: Re: Alpha Testing Underway!
Post by: Paul on December 07, 2011, 04:57:41 AM
Right, I know the XPeria keycodes, and that the supported Android key codes are < 255.  That's actually my concern - will these key codes > 255 be handled properly on the native side when using a NativeActivity, or does this only work with normal Activities which handle key input on the Java side (or does that make any difference?)  The easiest way will be for me to just try it, and it will either work or not, then I'll know  :)
Title: Re: Alpha Testing Underway!
Post by: firstpoke on December 07, 2011, 05:33:02 AM
The easiest way will be for me to just try it, and it will either work or not, then I'll know  :)

 ;)

I think thats the right way. But I dont think that will be a problem.
Title: Re: Alpha Testing Underway!
Post by: Mats on December 08, 2011, 10:53:04 AM
is gui a separate program that stops when you runs roms??
Title: Re: Alpha Testing Underway!
Post by: VioletLinked on December 08, 2011, 11:10:51 AM
The gui is not a seperate app. Gui is the graphical user interface. The gui can be activated by a button such as the menu button and will open up a setting menu for info, options, and button mapping and such. Im typing this from my android, sorry for errors
Title: Re: Alpha Testing Underway!
Post by: Mats on December 08, 2011, 11:42:27 AM
The gui is not a seperate app. Gui is the graphical user interface. The gui can be activated by a button such as the menu button and will open up a setting menu for info, options, and button mapping and such. Im typing this from my android, sorry for errors
so it wont have any effect on the speed on the emulator ?
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 08, 2011, 04:14:37 PM
if i understand Paul right, the gui is a separate thread and will be minimized or something of the sort so the emulator has focus, allowing it to engulf as much memory as it needs  ;)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 08, 2011, 04:23:24 PM
so it wont have any effect on the speed on the emulator ?
It shouldn't have any effect on the speed while the emulator is running, because in Android each frame is in its own separate Activity.  Only one is active and using the CPU and screen at a time (unlike windows which stack on top of each other).  It will of course use some memory for the static components (images, strings, etc), but that will be minimal and will have no effect on speed.  Emulation speed is affected mainly by processor, screen, and audio hardware usage, because the RAM is fixed,  So regardless of how much memory your device has, the emulator uses a fixed amount (it could crash if the device runs out of memory, but it won't slow down).  There could be some slow-down in the transitions (going from the menu to the game and vice-versa), but compared to how long it takes to resume the ROM anyway, I doubt it will be even noticeable.
Title: Re: Alpha Testing Underway!
Post by: firstpoke on December 08, 2011, 11:23:01 PM
Paul, If you have finished a stable version with GUI, then I will try it again. Maybe I can help you to optimize the Sound/Video laggs are still exist in the alpha version.
Title: Re: Alpha Testing Underway!
Post by: koekje on December 09, 2011, 04:29:47 AM
First of all great to see how you have progressed in the couple of months! I'm looking forward to you releasing this in the public :). I only have one concern, is it compatible with android 4.0?
Title: Re: Alpha Testing Underway!
Post by: Paul on December 09, 2011, 05:00:35 AM
I only have one concern, is it compatible with android 4.0?
I don't know.. someone will have to try it to see.  It should be if the API hasn't changed too significantly.  It may not take advantage of some new features of course, since it's written for API level 4 (Android 1.6).

Paul, If you have finished a stable version with GUI, then I will try it again. Maybe I can help you to optimize the Sound/Video laggs are still exist in the alpha version.
It will be ready soon.  I changed the way I'm handling configurations yesterday, which should make the logic a lot easier.  I'll try and get it out this weekend (I know, I said that last weekend..)  There really isn't much left to do, I just need to have the right combination of time, quiet, and motivation to finish it, haha.
Title: Re: Alpha Testing Underway!
Post by: rockNme2349 on December 09, 2011, 10:46:32 AM
First of all great to see how you have progressed in the couple of months! I'm looking forward to you releasing this in the public :). I only have one concern, is it compatible with android 4.0?

The November 5 Alpha Test is working fine for me on CM9 Alpha 11. (Nexus S)
Title: Re: Alpha Testing Underway!
Post by: koekje on December 09, 2011, 12:08:45 PM
Thanks :) will update soon to android 4.0 and wanted to know if i could test it on that version too :)
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on December 09, 2011, 01:42:58 PM
@ Paul and kris

Just for your lazy time ;)

A "nice" OT discussion came up in another forum about your ports, you should aware of it for your further development.

http://boards.openpandora.org/index.php?/topic/6071-yinlips-ydp-g18/page__st__60
Title: Re: Alpha Testing Underway!
Post by: Paul on December 09, 2011, 05:13:47 PM
Wow, the Pandora supporters on that OT discussion are really possessive about their ARM dynarec..  Thank God Ari64 isn't!
Title: Re: Alpha Testing Underway!
Post by: VioletLinked on December 09, 2011, 11:58:55 PM
Sorry to be off topic, but we need our voices heard: http://americancensorship.org/

please stop Protect IP! The internet is at stake!
Title: Re: Alpha Testing Underway!
Post by: Paul on December 10, 2011, 06:20:53 AM
Sorry to be off topic, but we need our voices heard: http://americancensorship.org/

please stop Protect IP! The internet is at stake!

While that site is a little overly dramatic, I definitely support any movement that stands against the government gaining more power.  Problem is, stuff like this will keep on popping up as long as lobbyists are allowed in Washington - that's what everyone should really be demanding their congressional representatives do something about.
Title: Re: Alpha Testing Underway!
Post by: TFreestone on December 10, 2011, 10:47:55 AM
Sorry to be off topic, but we need our voices heard: http://americancensorship.org/

please stop Protect IP! The internet is at stake!
Good move :) but i wouldn't worry too much. if stuff like youtube is banned armed protests will likely quickly resolve the issue. What with rioting happening in the UK over something trivial its even more likely to happen here if something is actually done that is worthwhile to riot about. not that rioting is good..
Title: Re: Alpha Testing Underway!
Post by: Paul on December 10, 2011, 01:01:36 PM
Getting back to the project: the new configuration interface I wrote is so much nicer than what I was using before.  Not sure if any of you had a look through some of the source code like GamePad.java and TouchPad.java, but it was pretty ugly.  The new interface is similar to a HashMap, except that the hashes are under their own sections.  I finished porting some of the existing source to this new interface, and it is very easy to read (and debug!) now.  I hope to have everything done soon (I'm shooting for this evening, but you know how that goes..)
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 10, 2011, 01:53:04 PM
This is what cleverbot thinks about the chances of the emulator being finished by tonight :P

(http://i.imgur.com/kVU8e.png)

Title: Re: Alpha Testing Underway!
Post by: Paul on December 10, 2011, 02:49:07 PM
Haha, that's not even as "clever" as my AI..

When I asked it, it told me "Well there is many people in Japan, I dot think you would have any trouble fusing someone."  Ok.. back to work.
Title: Re: Alpha Testing Underway!
Post by: kane on December 10, 2011, 03:28:46 PM
hello paul, once more thank you very much for all the time and all the hard work you are investing in this. Is the update going to be finished tomorrow? how much is left? I really hope you can finish it this weekend, but i can understand it if you can?t. I don?t want to put you under pressure, i just wanna know how far you are. :)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 10, 2011, 03:55:03 PM
I'm shooting for tonight on the update.  All that's left is a lot of tedious XML work, and I have to fix the file browser (I tried adding in the ability to browse through zip files the other day and totally screwed it up).  It will definitely be this weekend (might have to stay up late this evening.. I'll put on a pot of coffee).
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 10, 2011, 05:00:35 PM
I'm shooting for tonight on the update.  All that's left is a lot of tedious XML work, and I have to fix the file browser (I tried adding in the ability to browse through zip files the other day and totally screwed it up).  It will definitely be this weekend (might have to stay up late this evening.. I'll put on a pot of coffee).

I think browsing through zip files should be something thats optional. On my phone I have a folder full of zipped n64 roms and I think it would be a bit troublesome launching games if I have to do this:

roms>n64>mario.zip>mario.n64

Than doing this:

roms>n64>mario.zip

However I can see the advantages of it, if users dont already have their games zipped then they could add them all to one zipped archive and launch them like that:

roms>n64games.zip>allthegames.n64

anyway enough of my rambling good luck getting the final parts of the GUI done! :)
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on December 10, 2011, 05:01:16 PM
I'm shooting for tonight on the update.  All that's left is a lot of tedious XML work, and I have to fix the file browser (I tried adding in the ability to browse through zip files the other day and totally screwed it up).  It will definitely be this weekend (might have to stay up late this evening.. I'll put on a pot of coffee).

do what other people does: use the thing that lets you select a file manager you have installed on the smartphone, should work.
Title: Re: Alpha Testing Underway!
Post by: rockNme2349 on December 10, 2011, 06:10:38 PM
Along the same line as Epic_bubble,

I personally believe that if a zip file is chosen, the ideal behavior would be as follows:

If there is only one n64 file in the archive, it is loaded immediately.
If there are multiple files, it continues as planned.

I'm guessing this is already part of Paul's plan. If not it is a fairly trivial extension.

EDIT:

After further thought, the ideal behavior IMO would be to specify a rom directory in the options, then simply have a list of roms to launch. This would be more in-line with other emulators as well as android's vision of trying to make the user interact as little as possible with the file system.
Title: Re: Alpha Testing Underway!
Post by: Rarity on December 10, 2011, 06:15:47 PM
Epic, can't wait to try the new version once it's up. I haven't tried the Alpha yet due to sheer laziness, I was going to do that today but I may as well wait if there's the new version coming out xD.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 10, 2011, 06:40:06 PM
If there is only one n64 file in the archive, it is loaded immediately.
If there are multiple files, it continues as planned.
Yes, that is what I was trying to do.  I will probably come back to this later (it's a little more tricky than it sounds)

After further thought, the ideal behavior IMO would be to specify a rom directory in the options, then simply have a list of roms to launch. This would be more in-line with other emulators as well as android's vision of trying to make the user interact as little as possible with the file system.
I disagree that this would be ideal.  It creates extra steps for folks like me with tons of ROMs who want to organize them rather than throwing everything into a single folder.  The way I'm going to implement it is that it will remember which folder you were in last, and just start there when you come back.  I think that's the best compromise (folks with everything in one folder will have their list of ROMs every time, and everyone else can quickly choose "..", "folder", "ROM" if they are going from one collection to another.
Title: Re: Alpha Testing Underway!
Post by: rockNme2349 on December 10, 2011, 08:03:11 PM
I disagree that this would be ideal.  It creates extra steps for folks like me with tons of ROMs who want to organize them rather than throwing everything into a single folder.  The way I'm going to implement it is that it will remember which folder you were in last, and just start there when you come back.  I think that's the best compromise (folks with everything in one folder will have their list of ROMs every time, and everyone else can quickly choose "..", "folder", "ROM" if they are going from one collection to another.

Fair enough. I could see how that would be an issue if you had tons of roms.
Title: Re: Alpha Testing Underway!
Post by: Prophecy on December 10, 2011, 11:35:25 PM
I'm not sure if this was brought up already but.. When I reinstall the apk as I did before in the past, it doesn't work anymore. It just crashes on start-up. This didn't happen before.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 11, 2011, 01:52:23 AM
I'm not sure if this was brought up already but.. When I reinstall the apk as I did before in the past, it doesn't work anymore. It just crashes on start-up. This didn't happen before.

You'll have to manually install the old app-data or wait for the update

Speaking of which, the coffee is wearing off.. think I'll finish the update tomorrow.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 11, 2011, 12:39:57 PM
Ok so i asked cleverbot
Quote
Will paul finish his emulator tonight.
Probably not. What do you think?
Title: Re: Alpha Testing Underway!
Post by: Vincentmrl on December 11, 2011, 03:50:19 PM
the log cut the first part, asking cleverbot if Paul would ever finish emu, but the answer was random and i also re asked.

Quote
User: I am male.

Cleverbot: Elza is a feminine name.

User: My name is Vincent.

Cleverbot: What is your last name?

User: Not gonna tel.

Cleverbot: Haha ohm.

User: Mfw.

Cleverbot: Falsch.

User: Cake.

Cleverbot: Ekac.

User: Tobrevelc.

Cleverbot: What's 'Tobrevelc'?

User: It's Cleverbot backwards.

Cleverbot: How are you sure?

User: Because I'm human, now answer me if paul will ever finish Mupen64

Cleverbot: Good answer.

User: 1 3 3=.

Cleverbot: 0^0=?

User: No result.

Cleverbot: Which country am I from?

User: IF YOU DON'T KNOW.

Cleverbot: I do.

User: So why you ask.

Cleverbot: What did I ask you?

User: You asked me which country you are from.

Cleverbot: No I didn't.

User: You did.

Cleverbot: I didn't.

User: There's the Thoughts So Far Button, Want Me To Send You A Pic?

Cleverbot: There are lots of people I don't want to know.

User: /reset cleverbot.

Cleverbot: It's what you deserve, liar.

User: Will paul ever finish his emulator?

Cleverbot: Fairly unlikely, you are just a computer... What kind of computer are you?

User: I'm a mac, and you're a pc.

Cleverbot: I am definitely not a PC. I am as human as any human is.

User: Humanlike bot, I know.

Cleverbot: Yes yes yes.

User: You said yes, so you are a bot.

Cleverbot: NO.

User: You said yes, so you are a bot.

Cleverbot: NO.

User: Yes.

Cleverbot: Yes sir.

User: Now let's change argument: ever got Cave Story on Your Server?

Cleverbot: Are you trolling?

User: No.

Cleverbot: Thank you.

User: Answer the question now.

Cleverbot: What question!?

User: I asked you if you ever got cave story on your server/hard disk.

Cleverbot: Yes. I love someone.

User: Wh.

Cleverbot: Exactly.

User: NEVER GONNA GIVE YOU UP.

Cleverbot: I love that song.

User: Let's sing along so.

Cleverbot: What song.

User: Never gonna give you up, by Rick Astley.

Cleverbot: If that was your best attempt at a rock roll, you're doing it wrong.

User: Shutup.

Cleverbot: Shut who?

User: Your ass.

Cleverbot: Yes I know my age. What is yours?
Title: Re: Alpha Testing Underway!
Post by: Paul on December 11, 2011, 04:11:52 PM
I've had a serious headache today, and didn't make any more progress since last night.  I'm going to go ahead and post what I got done though, since I've been getting bombarded with messages from folks asking why the app is crashing (before they read the posts explaining that I'm in the middle of an update...)

ANYWAY, here it is:
Test APK (http://www.paulscode.com/source/Mupen64Plus-AE/11DEC2011/Mupen64Plus-debug.apk)  (if you want the source code before I finish the update, PM me)
Please delete the folder [sdcard]/app-data/paulscode.android.mupen64plus if you haven't yet

This will at least let folks use the emulator again.  I re-did the menu system and XML layouts, so almost nothing is actually hooked up at the moment besides choosing a rom and configuring the virtual gamepad.  Also, the "remember" code is not finished, so it forgets most of the choices you make when you navigate to a different screen.  Hooking all the options up to their functionality is very simple (only takes a couple minutes for each one), but there are a lot of options, so I'm looking at probably another 4-5 hours of development to get it finished.  I'll try and finish it up tomorrow if I'm feeling any better.  For whoever it was on here that was noticing the app crash due to lack of memory after I added the gles2rice plug-in, that's not fixed yet either (it ties into the plug-in chooser which isn't hooked up yet, sorry).

Please let me know if you find any bugs (keeping in mind of course that the GUI isn't actually finished).
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 11, 2011, 04:57:44 PM
Great work on the GUI paul, I tested it and I really like the layout. Obviously there are some problems mainly because its not finished yet but I think it would be better to report issues when everything is linked properly. :)

I cant test it extensively right now but I did try launching a rom and a nifty mupen64 3d banner thing popped up :P
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 11, 2011, 05:21:59 PM
@epic_bubble, it only does that for me on resuming a game because it defaults to the 1st rom in /sdcard/app-data/[mupen64plus]/roms/ which is the mupen64plus logo. Loading other my other roms is fine until trying to resume.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 11, 2011, 05:24:12 PM
@epic_bubble, it only does that for me on resuming a game because it defaults to the 1st rom in /sdcard/app-data/[mupen64plus]/roms/ which is the mupen64plus logo. Loading other my other roms is fine until trying to resume.

Loading other roms doesnt work for me, when I try it forces the app to run in the background and when I try to resume I get the mupen logo.

Could it be because all my roms are zipped?

EDIT: Yes unzipped roms work fine I just checked.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 11, 2011, 05:26:00 PM
yeah thats probably it, ive only tried unzipped roms *edit* zipped roms crash me
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 11, 2011, 05:27:30 PM
yeah thats probably it, ive only tried unzipped roms

Yeah that was the issue, unzipped roms work fine. :)
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 11, 2011, 05:30:04 PM
also just something i've noticed, Banjo Tooie seems to work better with the older versions of mupen64plus android edition than the newer ones  :P
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 11, 2011, 05:32:19 PM
also just something i've noticed, Banjo Tooie seems to work better with the older versions of mupen64plus android edition than the newer ones  :P

Do you have the onscreen controls enabled? By default the dynamic analog stick is enabled which can slow down gameplay, you can disable it in the settings.

(Im not sure if you would call it dynamic but its the one that moves) :P
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 11, 2011, 05:37:46 PM
i will after rebooting, just noticed a chunk of my mem is being used with who know what
Title: Re: Alpha Testing Underway!
Post by: Paul on December 11, 2011, 05:39:03 PM
when I try to resume I get the mupen logo.
Yes, the resume function is one of the things that isn't hooked up yet.  Like everything else, it is written (obviously), but still needs to be connected to the menu click.  I really should have hooked up the major things like resume and the plug-in chooser before I posted the apk, but my head is still pounding (probably had too much coffee last night, haha)

yeah thats probably it, ive only tried unzipped roms *edit* zipped roms crash me
Yes, I disabled the zip reading code until I get the rest of the GUI up and running.  This will be the next thing I fix.

also just something i've noticed, Banjo Tooie seems to work better with the older versions of mupen64plus android edition than the newer ones  :P
That would seem to indicate it is accessing memory outside of where it is supposed to be..  Since recent builds are using up more of the available memory, it becomes more likely that this will result in a crash.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 11, 2011, 05:50:33 PM
Dont worry paul take a rest, I think this test build will satisfy a lot of users for now. :)

hopefully you will get it finished soon so you can publish it to the android market and make some money for all your effort! ;D

And also when It is finished I will create a video walkthrough for the emulator showing off all its features so you could use that in the market description if you wanted.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 11, 2011, 05:52:00 PM
when I try to resume I get the mupen logo.
Yes, the resume function is one of the things that isn't hooked up yet.  Like everything else, it is written (obviously), but still needs to be connected to the menu click.  I really should have hooked up the major things like resume and the plug-in chooser before I posted the apk, but my head is still pounding (probably had too much coffee last night, haha)

yeah thats probably it, ive only tried unzipped roms *edit* zipped roms crash me
Yes, I disabled the zip reading code until I get the rest of the GUI up and running.  This will be the next thing I fix.

also just something i've noticed, Banjo Tooie seems to work better with the older versions of mupen64plus android edition than the newer ones  :P
That would seem to indicate it is accessing memory outside of where it is supposed to be..  Since recent builds are using up more of the available memory, it becomes more likely that this will result in a crash.
Here is typical behavior with banjo tooie:
The rom loads fine as shows the intro perfectly, and then when the scene changes to the file select, it crashes. this happens with any scene change
and yeah thanks for the gui :D
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 11, 2011, 05:59:41 PM
Yay I can see my volume button idea was added. :)

(http://i.imgur.com/FOgqq.png)(http://dl.dropbox.com/u/13594612/paulscode/screenshot_2011-12-11_2359.png)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 11, 2011, 07:12:57 PM
Yay I can see my volume button idea was added. :)
It is a great, simple idea.  This is one of the few things that's actually hooked up right now, BTW (although it still "forgets" what you picked once you leave the game activity or close the app).  I think I'll leave this setup in place.. the other way would probably just end up confusing people.

hopefully you will get it finished soon so you can publish it to the android market and make some money for all your effort! ;D
Yes, I'm hoping to sell enough copies to afford some various hardware to help with the project.  In particular, I'd like to get my hands on a variety of joysticks.  I'd also like to get a Pandora once they start production on them again, so I can more easily develop a patch for the official Mupen64Plus project that adds support for Android and Pandora.  And not to be greedy, but an XPeria Play would be nice too  ;D
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 11, 2011, 07:25:41 PM
Xperia Plays are relatively cheap depending on what model you want  (especially compared to pandoras) ;D
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 11, 2011, 08:00:29 PM
Hey Paul I found this and it looked like something you might be interested in, a guy has put a video up on YouTube showing how to create a NES emulator from scratch in half an hour! There are never usually videos about emulator development and it's crazy to see him code it that fast.

http://www.youtube.com/watch?v=y71lli8MS8s
Title: Re: Alpha Testing Underway!
Post by: Paul on December 11, 2011, 08:06:12 PM
Haha, wow..  There's somebody with way too much time on his hands.  Even though it is sped up, he still would have needed to spend months memorizing every line of code to be able to pull off a video like that (or maybe he has a photographic memory).

-- On second thought, he probably did that with a keystroke recorder.  Still impressive, though - he makes very few mistakes.
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on December 12, 2011, 05:25:52 AM
The rice plugin works much better. still some bugs, but some things are fixed now. the gui looks good.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 12, 2011, 06:10:49 AM
This is the coolest thing I've seen in a while...


(source code (http://www.paulscode.com/games/vNES/vNES_215_Source.zip))
Title: Re: Alpha Testing Underway!
Post by: neo3 on December 12, 2011, 08:13:38 AM
Hi Paul,

I see that your emulator is getting very good, congratulations for the work!

I tested now in my Galaxy Ace with Gingerbread 2.3.4, and is running reasonably, I wanted to disable the audio to see if the game speed increases, but this makes me more anxious to see the stable version.

I found a strange thing, at the beginning of the Zelda, when he goes out of his house that shows a top view, the house appears green without the textures of the wood of the house.

And one suggestion I wanted to give, if you can increase the size of the display of the FPS of the gamepad small, because here in my Galaxy Ace i can't see the number of frames right.

Congratulations again at work!
Title: Re: Alpha Testing Underway!
Post by: Mats on December 12, 2011, 08:39:28 AM
The gui is looking good but when i try to load a rom it crash and the app ends is this becuse it unstable ??? i have a xperia x8.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 12, 2011, 08:54:55 AM
The gui is looking good but when i try to load a rom it crash and the app ends is this becuse it unstable ??? i have a xperia x8.

Looks like you were the one I was talking about...

all the builds before the package got 2 mb works and the last build that work is : ARM6, VFP Test

For whoever it was on here that was noticing the app crash due to lack of memory after I added the gles2rice plug-in, that's not fixed yet either (it ties into the plug-in chooser which isn't hooked up yet, sorry).
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 12, 2011, 10:10:20 AM
That vnes emulator is pretty amazing! this is even cooler though, its a GBC emulator made in HTML5 (and probably some other stuff too). I can run it on my iPad without needing to jailbreak (since its all html5) but it runs super slow. Work fine on my desktop though.

Link: http://www.grantgalitz.org/gameboy/
Title: Re: Alpha Testing Underway!
Post by: maciek9971 on December 12, 2011, 10:15:28 AM
Hello Paul,

In latest Test App when i have to open rom, emulator is always closing before running a game. I have Xperia x10 mini pro and i dont know what should i do. Help :P

Sorry for my bad english.  ;)
Title: Re: Alpha Testing Underway!
Post by: mas on December 12, 2011, 11:03:35 AM
Hey Paul,

    First, let me say that I'm enthralled that N64 has been brought to Android. I am running your emulator on the original Droid. The emulator is working fine, but I was wondering if there was a way to boost the frame rate on this. Was this device meant to run the emulator smoothly? Please let me know your thoughts.

With much appreciation,
                        Michael S.
Title: Re: Alpha Testing Underway!
Post by: TFreestone on December 12, 2011, 11:45:10 AM
I found a strange thing, at the beginning of the Zelda, when he goes out of his house that shows a top view, the house appears green without the textures of the wood of the house.
i noticed that too. It has to do with a bug in the default plugin in rendering 2d textures, such as link's house and the entrances to the Castle Market and Temple of Time. It may or may not be fixed in a later update to the plugin.

@Paul - This particular thread is the Testing/discussion thread correct? Might i suggest making separate threads for Bug reports, tesing, etc. and then another one for QandA / Support as well as maybe a sickie for people who are new to the project and need to learn the basics, to avoid every new person asking the same questions and so on.

@Everyone - Check back a few pages (or all of them ;) ) and make sure your question hasn't already been answered.
Title: Re: Alpha Testing Underway!
Post by: kane on December 12, 2011, 12:52:57 PM
thank you very much, the emulator works. you really did a good job, but i have got a question. the fps is very low (around 9-12), and the video + audio is laggy. is there a way to change that?
Title: Re: Alpha Testing Underway!
Post by: tgwaste on December 12, 2011, 03:10:23 PM
Working very well so far although I still wish it didn't use the archaic app-data directory or at least let us specify where the program files live. :)  Well done though.  I really like the Simple GUI.
 
Title: Re: Alpha Testing Underway!
Post by: Prophecy on December 12, 2011, 03:17:37 PM
I'm pretty sure most of us are experiencing low frame rates since we are running arm v6. The best thing we could have to ease the issue a tiny bit is probably an option for frame skips. I use up to around +10-20 frame skips for my playstation emulator and it works much better. Dunno if that was already suggested though o.O
Title: Re: Alpha Testing Underway!
Post by: Paul on December 12, 2011, 04:03:28 PM
Hello Paul,

In latest Test App when i have to open rom, emulator is always closing before running a game. I have Xperia x10 mini pro and i dont know what should i do. Help :P

Sorry for my bad english.  ;)
That's the same device Matts has, right?  I'll fix this next and try to post an update tonight.

thank you very much, the emulator works. you really did a good job, but i have got a question. the fps is very low (around 9-12), and the video + audio is laggy. is there a way to change that?
Which ROM, and what is your device?  The emulator will improve over time with optimizations, but don't expect it to happen overnight.

The best thing we could have to ease the issue a tiny bit is probably an option for frame skips.
Yep, that's one of the things that's high on my priority list.

Working very well so far although I still wish it didn't use the archaic app-data directory
This will be changed in the official build before I list it on the market (this version was just a quick update to stop the flood of emails asking why the emulator was crashing).

I am running your emulator on the original Droid. The emulator is working fine, but I was wondering if there was a way to boost the frame rate on this. Was this device meant to run the emulator smoothly? Please let me know your thoughts.
The original Droid is only 600MHz, so it will probably be a while before the emulator runs smoothly on it.  Optimizations are going to be my secondary focus in the Beta testing phase after bug-fixes.
Title: Re: Alpha Testing Underway!
Post by: tgwaste on December 12, 2011, 04:23:27 PM
I also get low 9-12 framerates whem playing.  im playing zelda oot on a htc thunderbolt.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 12, 2011, 04:24:40 PM
@Paul - This particular thread is the Testing/discussion thread correct? Might i suggest making separate threads for Bug reports, tesing, etc. and then another one for QandA / Support as well as maybe a sickie for people who are new to the project and need to learn the basics, to avoid every new person asking the same questions and so on.
The Beta testing phase will also see changes to the forum boards.  Mupen64Plus-AE will be given its own category with boards for announcements, support, game compatibility, bug reports, and general discussion.  This particular thread will be in the announcements board, renamed "Alpha Testing History", and be locked.  A new thread called "Beta Test [ver #] Released!" will be created, and the .APK ad source-code will be available there.  A new thread will be created for each major update.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 12, 2011, 04:29:06 PM
I also get low 9-12 framerates whem playing.  im playing zelda oot on a htc thunderbolt.
Yes, the higher-end games like the Zelda games (and don't get me started on Conkers) run slow for everyone, even us lucky ARM7a + Neon folks.  You can improve the speed by overclocking, but ultimately the solution will be lots of optimizations over time.
Title: Re: Alpha Testing Underway!
Post by: tgwaste on December 12, 2011, 04:51:41 PM
Cant wait to see the speeds on the Galaxy Nexus :)
Title: Re: Alpha Testing Underway!
Post by: formiga on December 12, 2011, 05:33:58 PM
The emulator on my ARMV6 device runs Mario64 near full speed(25-30fps)! Really thanks for this emulator!
Title: Re: Alpha Testing Underway!
Post by: Paul on December 12, 2011, 10:55:32 PM
I didn't have much time for programming this evening, but I managed to finish the plug-in configuration stuff.  This should fix Mats' and maciek9971's crash problem (if not, could one of you please post a logcat after the crash happens?)

It was necessary to also implement part of the "remember" code, but it is not complete yet.  I wouldn't be surprised if the config files get corrupt when doing various things, since it's only halfway implemented.  If that happens (menu or emulator crashes, virtual gamepad looks weird, etc), just refresh the app-data folder to fix it.

Also, for those who have small screens, please refresh your app-data folder and let me know how the larger font looks when the FPS indicator is on.

Test APK (http://www.paulscode.com/source/Mupen64Plus-AE/12DEC2011/Mupen64Plus-debug.apk)
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 13, 2011, 06:33:36 AM
I think it would probably be a good idea to continue testing the current builds with an unzipped mario 64 rom. That way you can be sure the crashes are not being caused by the roms.
Title: Re: Alpha Testing Underway!
Post by: sergioc on December 13, 2011, 08:14:10 AM
Thank you very much.....in xperia x10 mini pro it runs now, the only problem is the key mapping, it doesnt recognize the keys in the input settings and the virtual pad is too big but im not sure about what app-data folder i have to replace by to fix that, with the old app-data folder i just see the stick and the mario rom into the app runs about 13 fps without overclocking :P , thks again!! cant wait too see the final version
Title: Re: Alpha Testing Underway!
Post by: Mats on December 13, 2011, 08:43:06 AM
here is the logoutput Paul, it works ! but ven i disable the audio plugin it crash and is it possible to add frameskips so it wont lag so much ?
Title: Re: Alpha Testing Underway!
Post by: neo3 on December 13, 2011, 09:26:40 AM
Also, for those who have small screens, please refresh your app-data folder and let me know how the larger font looks when the FPS indicator is on.

(http://lh6.ggpht.com/-uc7ywzxtjHg/TudtM7Vrb7I/AAAAAAAAA18/2gwAQbnWO1M/SC20111213-131408.png)

If you want, I think can decrease a little.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 13, 2011, 09:54:38 AM
I have an idea for the emulator for the way the touch screen controls are displayed.
I dont know if this is possible in android but heres me idea:

Get users screen size
If screen size > x then use mupen64-ae analog //whatever size

So if the users screen if larger or smaller then a certain size the first time mupen is launched it will set the appropriate control size for that user.

Only make it do this on the first launch after installing or else it will override the users current settings.

Its hard to explain what I mean but im sure you understand.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 13, 2011, 02:00:56 PM
I think it would probably be a good idea to continue testing the current builds with an unzipped mario 64 rom. That way you can be sure the crashes are not being caused by the roms.
theres always the tiny mupen64plus.v64 rom thats included ;)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 13, 2011, 02:35:18 PM
I think it would probably be a good idea to continue testing the current builds with an unzipped mario 64 rom. That way you can be sure the crashes are not being caused by the roms.
Yes, I forgot to mention, the .zip reading is still disabled.  I'll be sure to mention when I get it working properly.

the only problem is the key mapping, it doesnt recognize the keys in the input settings
The key listener is not hooked up yet (the listener is coded, but I haven't figured out how to receive key input from a custom dialog box yet -- the usual way doesn't work).  I'll post questions on various Android development sites tonight to see if someone knows.  I might end up having to get rid of my beautiful dialog box if I can't figure it out..  :'(

and the virtual pad is too big but im not sure about what app-data folder i have to replace by to fix that
This parts already coded into the GUI and working.  From the main menu, go to Skins->Virtual Gamepad->Change and select the layout you want to use from the list (probably one of the "Small" or "Tiny" layouts).

So if the users screen if larger or smaller then a certain size the first time mupen is launched it will set the appropriate control size for that user.

Only make it do this on the first launch after installing or else it will override the users current settings.
I'm way ahead of you -- I thought of this idea but haven't implemented it yet.. it will be in the next release (I'll post an update tonight whether or not I have time to finish the GUI).
Title: Re: Alpha Testing Underway!
Post by: Paul on December 13, 2011, 03:15:40 PM
Paul, it works ! but ven i disable the audio plugin it crash
This doesn't happen for me.  The "Enable" checkbox isn't working for me, but no crash.  I'll get it working and see if that fixes your problem as well.

Could you try librsp-hle-nosound.so see if it works for you (choose it in the the RSP plug-in section, not the audio plug-in section.. I might need to come up with something to make this more clear, haha).

and is it possible to add frameskips so it wont lag so much ?
From what I've gathered, this function was handled differently in different versions of gles2n64.  I haven't looked that closely at this part of the code for the version I'm using to know how to configure it (it would be done through the config file).  This is one of the areas I will focus on after finishing the GUI.  I need to get my hands on the source code for a couple builds of gles2n64 from the Pandora project for comparison, and figure out which version works best for most folks.
If anyone can help me locate the versions of gles2n64 from the Pandora project that seem to have been removed, I'll look into this sooner rather than later..
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 13, 2011, 03:31:12 PM
found this on the maemo website: http://repository.maemo.org/extras-devel/pool/fremantle/free/source/m/mupen64plus-arm/mupen64plus-arm_20100627.orig.tar.gz
appears to be the same thing as the pandora source? idk
Edit: yeah appears to be glide64 and gl64 in there if those are what you want
Title: Re: Alpha Testing Underway!
Post by: Paul on December 13, 2011, 03:50:13 PM
Yes, I have that, it's just the emulator itself.  As I recall, the gles2n64 plug-in development was done separately, and there are at least 2 versions which had frameskip added (something like "r4b" and "r5", but I can't remember off the top of my head).  They both handled frameskip differently (as I recall one allowed like one or two frames to be skipped and the other allowed you to specify a number.. don't quote me on that).  The version I'm using is a hybrid of Yongzh's, Zodttd's, and Lachlan's code, so I have no idea what's in there and what needs to be added for frameskip to work (I'd be willing to bet it is broke at the moment).  That's why I need some different versions for comparison before I can get an idea of how it is supposed to be implemented.

--EDIT--
I did a little digging through the code, and it looks like the frame skipping stuff is there, but just not hooked up.  There is the following callback, which is not part of the official Mupen64Plus API, and is not being called from anywhere in the code:
Code: [Select]
EXPORT void CALL SetFrameSkipping(bool autoSkip, int maxSkips)
{
    frameSkipper.setSkips(
            autoSkip ? FrameSkipper::AUTO : FrameSkipper::MANUAL,
            maxSkips);
}
Presumably, this is called from the front-end (I'm pretty sure the Pandora versions allowed you to configure this through the config files, not via a callback, so this is probably something Yongzh came up with).  Looking at the config file, it seems to be written for a different version of gles2n64 (several parameters are missing or simply ignored) - I'm assuming Yongzh pulled functionality out of the config files to move it to the GUI instead.  I'll play around with the code to see if frameskip actually works when I call the callback.  From the code, it looks like "autoSkip"" is supposed to cause frameskipping to change dynamically to try and achieve the target FPS, or if set to manual, you define the maximum skips yourself.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 13, 2011, 04:54:35 PM
Yep, frameskip works.  I can get Zelda to emulate at full speed with no audio glitches using a frameskip of 4 (slows me down to 3 FPS though  :P)  I'll implement an interface for this after I finish the GUI (I'll need to move stuff back into the config file to work with the way I implemented the GUI, which reads/writes from the config files, rather than whatever method Yongzh's N64oid GUI uses)
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 13, 2011, 05:20:00 PM
Sounds good. I wonder if Banjo Tooie might work better  8)
Btw, also tweeted to zodttd about this project in case he hasn't found it yet ;)
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 13, 2011, 05:28:22 PM
Sounds good. I wonder if Banjo Tooie might work better  8)
Btw, also tweeted to zodttd about this project in case he hasn't found it yet ;)

zodttd definitely knows about this project, I remember him posting here before and he asked if paul wanted his unfinished n64droid source.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 13, 2011, 05:40:50 PM
Yes, Zodttd helped me solve the "black screen" bug that had the project at a standstill for almost six months.  He emailed me the source code for his unfinished Android port of gles2n64, and suggested where the problem might be located (which gave me some more code to compare and tinker with and eventually get a working plug-in).
Title: Re: Alpha Testing Underway!
Post by: Paul on December 13, 2011, 09:36:08 PM
I hooked up nearly all of the remaining functionality besides the key listener, which I'm waiting for a necessary piece of information before I can do that.  Unfortunately, I broke the golden rule of development, which is to never do too much at once between tests.  I seem to have introduced some instability, and I can't figure out what's causing it.  Basically, going back from the game to the menu, or from the game to the home screen then to the menu causes the app to crash.  Logcat is useless (stack trace full of libc calls).  My initial thought was that it was the save-state code that was causing it, but I commented that out and it still crashes, so it is definitely something else.  I'm going to have to back-track a bit and disconnect stuff once again until I figure out what's causing the crash.

Additionally, I haven't been able to figure out why disabling the audio plug-in doesn't work.  I can verify that the GUI removes the path from the config file (I've also manually removed it just to be doubly sure).  It is definitely still gone from the config file when Mupen64Plus starts up.  I've also removed the "default plug-ins" list that was hard-coded in, so it isn't getting loaded from there.  I even did a file-system search for the string "audio-sdl" and can not find where it is being loaded from in the code.  But every time (unless I enable the rsp-hle-nosound RSP plug-in), the sound always plays!   ???  I pretty much spent all evening trying to figure out why..  I'm sure it is something obvious and I'm going to feel stupid when I figure it out.

Anyway, in case folks want to try it, here it is.  Once again, it is not stable, and will crash every time you go to the menu after running a game


Test APK (http://www.paulscode.com/source/Mupen64Plus-AE/13DEC2011/Mupen64Plus-debug.apk)
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 14, 2011, 04:54:55 AM
Quote
[Additionally, I haven't been able to figure out why disabling the audio plug-in doesn't work.  I can verify that the GUI removes the path from the config file (I've also manually removed it just to be doubly sure).  It is definitely still gone from the config file when Mupen64Plus starts up.

I know its not a good idea to use hacky work arounds but is it possible to move the audio plugin to a temporary folder when the user chooses to disable the audio plugin? That way the emulator couldn't use it at all.

If I remember correctly the plugin is stored somewhere which required root to access though. :/

EDIT: there definitely something wrong with the audio settings. Even when I change the plugin to something ridiculous like a video plugin it still plays audio.
Title: Re: Alpha Testing Underway!
Post by: neo3 on December 14, 2011, 06:38:44 AM
Quote
[Additionally, I haven't been able to figure out why disabling the audio plug-in doesn't work.  I can verify that the GUI removes the path from the config file (I've also manually removed it just to be doubly sure).  It is definitely still gone from the config file when Mupen64Plus starts up.

I know its not a good idea to use hacky work arounds but is it possible to move the audio plugin to a temporary folder when the user chooses to disable the audio plugin? That way the emulator couldn't use it at all.

If I remember correctly the plugin is stored somewhere which required root to access though. :/

EDIT: there definitely something wrong with the audio settings. Even when I change the plugin to something ridiculous like a video plugin it still plays audio.

I also selected another plugin in audio, but seems to have no change. In the video, yes, I changed to another plugin and the emulation slowed.
Title: Re: Alpha Testing Underway!
Post by: Mats on December 14, 2011, 01:19:39 PM
if i have n64oid and take the audioplugin or videoplugin in use on mupen64plus would it work?
Title: Re: Alpha Testing Underway!
Post by: Paul on December 14, 2011, 01:28:33 PM
No.  Yongzh altered the official Mupen64Plus 2.0 API considerably.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 14, 2011, 04:02:36 PM
I know its not a good idea to use hacky work arounds but is it possible to move the audio plugin to a temporary folder when the user chooses to disable the audio plugin? That way the emulator couldn't use it at all.
Actually, an even better solution might be to change the name of the plug-in library all together.  Since I'm planning on altering it anyway (to allow for dynamic framerates to eliminate skipping), I should rename it anyway so it isn't confused with the official audio plugin.  I'm also going to do some tests on the PC version to see if this bug exists in the official Mupen64Plus, and let Richard42 know if it does.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 14, 2011, 04:39:07 PM
I'm still wondering if the early Majora's Mask hang is only on my port or if its a fix not in the current source release of n64oid.

Kris, did you base your core library off of the code for n64oid, or Mupen64Plus AE (or another project all together)?  I recall seeing various changes to the source code in Yongzh's project (either the core or the rsp plug-in, near some comments about Zelda) a few months ago when he released one of the versions on Source Forge (the second one I think).  I haven't gone back to see what this stuff is related to (I've been trying to get all the basics in place first).  The solution may be in there.  Also, it might be worthwhile to ask some of the Pandora folks if the problem exists in Ari64's project (if not, that could narrow down the search to the main sections of code that are different between versions 1.5 and 1.99.4 - better than starting from scratch anyway).  Let me know if you find a solution (and I'll do the same).
Title: Re: Alpha Testing Underway!
Post by: Kris on December 14, 2011, 06:40:54 PM
I've been using the core from n64oid, I haven't made any compatibility fixes to the core the only changes were to get it to running on webos, some sdl stuff and __clear_cache mainly. I don't know if things have changed since but here (http://boards.openpandora.org/index.php?/topic/2200-mupen64plus-new-version-runs-zelda-oot-and-much-more/page__view__findpost__p__84728) is a post indicating the same zelda problem occurs on the pandora. I haven't had a good look through the debugger yet but the emulator still responds to pause and resume, there is some mention about changing framebuffer settings aswell which I haven't tried nor have I looked at using a save further into the game.

I'm hoping to fix Yoshi's Story in rice, I've found the same problem happens with with original version if you compile without asm so that narrows things down a bit, I've sorted the missing menu backgrounds on Mario Kart but the drivers are still facing backwards :/

I think I previously mentioned it a while back the missing backgrounds in gles2n64 and Ocarina of Time is due to gSPBgRectCopy in gSP.cpp:1561 returning early. You can checkout earlier versions of gles2n64 from the google code page but I haven't looked closely.

When you mention the api changes Yongzh made what are you referring to? Other than ReadScreen/ReadScreen2 I can't think of much else.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 14, 2011, 07:03:30 PM
I found the code I was talking about again (in the rsp plug-in, ucode1.cpp, ucode2.cpp, and ucode3.cpp)..  Definitely looks like logic error fix, but unrelated to the Majora's Mask crash.  There is also another logic error fix I found in the core, rom.c.  Line 100 should read localrom=localrom[i+3]; (not localrom=localrom[1+3];).  I don't see any visible differences with these fixes in place, though, so they must not be very important.  You already have these fixes anyway, since you are based on n64oid (they'll mainly benefit Richard42 if he hasn't found them already).

I think I previously mentioned it a while back the missing backgrounds in gles2n64 and Ocarina of Time is due to gSPBgRectCopy in gSP.cpp:1561 returning early. You can checkout earlier versions of gles2n64 from the google code page but I haven't looked closely.
Thanks, I'll definitely take a look into this and let you know what I find out.

When you mention the api changes Yongzh made what are you referring to? Other than ReadScreen/ReadScreen2 I can't think of much else.
Well, I don't mean documented API specifically, but to the assumptions made in the code for how things are linked, where functions are located, and what calls what from where (which are every bit as important).  I may be wrong to refer to this as the "Mupen64Plus API", but I don't have a better term.  Since you had to add the SDL linkage back into Yongzh's code, I'm sure you know what I'm talking about.  It's the little things that make his specific plug-ins only work with his emulator.  Part of the reason was the removal of SDL, and part was to control things from the central GUI, and part was to keep the closed-source components he wrote separate from the open-source code.  By comparison, plug-ins written for PC Mupen64Plus, if recompiled for the ARM architecture, should work "out-of-the-box" in Mupen64Plus AE (at least that is the goal.. to have a source code base from which patches could be easily applied back to the official Mupen64Plus project, and vice versa).  The exception, of course, is the video plug-ins, which require a JNI linkage to flip the EGL buffers -- but then they wouldn't work "out-of-the-box" anyway due to GLES, so I don't feel too badly about that!  The GUI interfaces with unique features of the plug-ins (such as "frame skip", "screen stretch", and so on) through their config files rather than linking with the plug-in directly through an altered API with linkage to JNI.  That allows me to leave the plug-in code virtually unaltered and still portable.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 14, 2011, 07:46:33 PM
Ok, reading back on my last post, it seems like a bit of a rant.  Let me put it a simpler way.  Take a look at Ari64's project, and then look at Yongzh's.  Ari64's code is not just a Pandora port with an ARM dynarec - he has improved the x86 and x86_64 dynarecs as well, and set it up so it can be built cross-platform.  Which one adheres to the  philosophy of collaboration and open-source?  That's what my goal is with this project (obviously I'm not there yet, but I will eventually.)  Hell, Yongzh's code isn't even complete!
Title: Re: Alpha Testing Underway!
Post by: ulquiorra on December 14, 2011, 07:51:42 PM
Hello, This emulator work on samsung galaxy Ace?
I have not got this phone, but I buy
i use google translate for this XD
Title: Re: Alpha Testing Underway!
Post by: Paul on December 14, 2011, 08:24:08 PM
Yes, folks have reported it working on the Galaxy Ace.  It will run slowly though, because it has one of the ARM6 chip-sets.  Besides rooting and over-clocking if possible, optimizations you can use in the upcoming version to make games more playable are to disable the audio plug-in, use the rsp-hle-nosound RSP plug-in, disable the virtual game-pad (or at least use one of the "touch" layouts with FPS disabled), use the gles2n64 video plug-in, disable screen stretch, and use frameskip.
Title: Re: Alpha Testing Underway!
Post by: ulquiorra on December 14, 2011, 08:45:42 PM
ok, thank you very much for your great work friend.
FOR MORE UPDATES WILL BE PENDING!!! :D Thanks
Title: Re: Alpha Testing Underway!
Post by: Paul on December 14, 2011, 08:51:38 PM
(http://www.paulscode.com/images/pending.jpg)

(that's a poke at Google Translate, not your language skills) :P
Title: Re: Alpha Testing Underway!
Post by: ulquiorra on December 14, 2011, 09:02:36 PM
(that's a poke at Google Translate, not your language skills) :P

my english no is very good sorry XD
but excelent work whit this emulator. (this is my english jeje)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 14, 2011, 09:06:29 PM
No problem, I was just laughing that the program chose "pending" rather than the more obvious word "waiting".  Sounds like something a computer would say (oh wait, it is a computer!)  ;D

I figured out a couple more things you could have meant..

"More updates will be outstanding".  The word "outstanding" translates to "pendiente".  However, another translation for "pendiente" is "pending".  "Pending" means "espera de".  Thus the confusion.

"For more updates(, I) will be watching".  "Pendiete" can also translate to "watching".  If a word were missing, I could see this translation happening.  A better translation would be "I will be watching for more updates"

And the most likely meaning:

"I will be waiting for more updates" (Estar? esperando m?s actualizaciones).  This could happen if google got the grammar backwards.  I'm pretty sure this is what you meant to say.

Anyway, my Spanish skills are worse than your English, so don't worry.  ;)
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on December 15, 2011, 11:02:03 AM
The actual version of Pixel Dancing Studios " Sixaxis Controller " now supports mapping for touchinput. So you can map one hardware analog stick to the virtual stick to controll it.
So analog input for Sixaxis gamepads is possible on mupen64plus-ae, even if it's not implemented.
Title: Re: Alpha Testing Underway!
Post by: tgwaste on December 15, 2011, 05:24:27 PM
Galaxy Nexus will be here tomorrow.  Wonder if M64P will run... :)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 15, 2011, 08:37:10 PM
I figured out the issue with the audio.  It seems that if Mupen64Plus fails to load the plug-in specified in the config file, it searches the plug-ins directory for an alternate audio plug-in to use (the name doesn't matter).  Frankly, I find this behavior extremely presumptive and even potentially dangerous..  This is the first real criticism I have with the emulator and something I will definitely discuss with Richard42 about changing.  In the mean time, I still want to remain true to the original project, so I'm not going to "fix" the code.  There are other ways to disable the audio besides through the config files (there is an interface in the API for example), so I'll just hook it up a different way.
Title: Re: Alpha Testing Underway!
Post by: Mats on December 16, 2011, 06:49:10 AM
I figured out the issue with the audio.  It seems that if Mupen64Plus fails to load the plug-in specified in the config file, it searches the plug-ins directory for an alternate audio plug-in to use (the name doesn't matter).  Frankly, I find this behavior extremely presumptive and even potentially dangerous..  This is the first real criticism I have with the emulator and something I will definitely discuss with Richard42 about changing.  In the mean time, I still want to remain true to the original project, so I'm not going to "fix" the code.  There are other ways to disable the audio besides through the config files (there is an interface in the API for example), so I'll just hook it up a different way.
nicce, but in the next test could you include frameskip, or takes it time to include in the gui ?  ;)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 16, 2011, 09:35:12 AM
nicce, but in the next test could you include frameskip, or takes it time to include in the gui ?  ;)
Yes, I've added a quick hack into the code to give folks access to it.  Of course, it only works with the gles2n64 plug-in (so it won't help Conkers).  I honestly don't really like it myself.  I'd almost rather have the audio disabled and the emulation speed a tad slow than to have the emulation speed normal with a low frame-rate (but to each his own, I suppose).  This is definitely not the ideal solution for improving performance (needs more tangible optimizations, IMO).

Anyway, here's the latest build.  All the plug-in "disable" buttons still don't function (it isn't just audio that Mupen64Plus automatically loads - it's all of them).  I'm thinking the best solution will be to compile "dummy" dynamic libraries, so Mupen64Plus feels happy that it loaded a plug-in (and the plug-in will simply not do anything, essentially disabling it).

 Someone recently accused me of violating the GPL with the recent post-GUI updates, so just to make it clear: as I stated before, if anyone wants the source code before I finish updating, just PM me and I'll send it to you (I'm just trying to avoid folks starting branches of the project in its current incomplete state, but if you really want the code right now, its yours).

It's really almost complete, I just need to implement the plug-in disabling, fix a bug with gles2rice when choosing "Close" from the in-game menu, and implement screen-stretch in gles2rice (maybe one or two other small things, I'll have to play around with the menus to see if I missed anything)

Test APK (http://www.paulscode.com/source/Mupen64Plus-AE/16DEC2011/Mupen64Plus-debug.apk)
Title: Re: Alpha Testing Underway!
Post by: tgwaste on December 16, 2011, 11:47:50 AM
.zip files supported in this latest version?
Title: Re: Alpha Testing Underway!
Post by: Paul on December 16, 2011, 11:50:01 AM
.zip files supported in this latest version?

No, that's the other thing I need to hook up (I knew there was something!)

--EDIT-- I hooked it back up (will be in the next version).  I'm leaving out the zip-browsing capability for now, because it just screws everything up when I try to add it (this feature is pretty low priority, so not worth the effort at the moment).
Title: Re: Alpha Testing Underway!
Post by: bart2465 on December 16, 2011, 04:51:15 PM
worms armageddon doesn't work. does anyone how to fix it?

sorry for my bad english
Title: Re: Alpha Testing Underway!
Post by: Paul on December 16, 2011, 04:56:55 PM
Whew, finished with the GUI.  Obviously there is still plenty of room for improvement.  In particular, it is really easy to crash the app if you do stupid things in the setting menu (like disabling RSP, disabling input then pressing buttons, etc.) but I don't think that will bother most users too much.  The in-game menu is a bit sluggish when you chose "Menu" or "Close".  I can improve this by moving the state-save stuff out of the main UI thread (I want to make sure it works on other devices in its simplest form first before I start playing with threads and ANR again).

Anyway, I'm calling this the "final Alpha test".  All that's left to do is to comment a few parts of the code better, and clean up a couple quick hacks I added.  Once that's done and several people run the test and we work out any bugs, I plan to move on to the Beta testing phase (hopefully this weekend).

Final Alpha Test (http://www.paulscode.com/source/Mupen64Plus-AE/16DEC2011/Mupen64Plus-debug-final-alpha.apk)   (source code (http://www.paulscode.com/source/Mupen64Plus-AE/16DEC2011/mupen64plus-SDL1.3-source.zip))

IMPORTANT: Please delete the folder [sdcard]/app-data/paulscode.android.mupen64plus  The app data is no longer stored there, so no reason to waste space on your SD Card.  App data has been moved to the standard folder [sdcard]/Android/data/paulscode.android.mupen64plus.  If you don't have any of Pelya's apps installed on your phone, [sdcard]/app-data will probably be empty and you can just remove it as well.

Next I'm moving on to setting up the Xperia Play mirror project so it shares the native sources with the main project.  I'll hopefully have that done tomorrow.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 16, 2011, 06:51:48 PM
Nice! i find my settings of disabling the virtual gamepad aren't being saved though. Frameskip seems to be saved at least so thats good
The auto frameskip setting helps with banjo tooie alot. It works better in this version than previously :D
Title: Re: Alpha Testing Underway!
Post by: Paul on December 16, 2011, 06:55:01 PM
Thanks, I'll look into the virtual gamepad settings.  It was saving before, but I might have broken it.  Let me know if you find anything else not being remembered.

Yep, looks like I disconnected it (must have been when I was unplugging everything to try and fix that menu crash bug).  Nice catch!
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 16, 2011, 06:57:23 PM
Thanks, I'll look into the virtual gamepad settings.  It was saving before, but I might have broken it.  Let me know if you find anything else not being remembered.
i also noticed the analog stick mapping seemed to be reversed for up/down
and when the virtual gamepad IS enabled, banjo tooie wont load
Title: Re: Alpha Testing Underway!
Post by: Paul on December 16, 2011, 07:01:36 PM
Wow, you're right.. how'd I miss that?
Title: Re: Alpha Testing Underway!
Post by: Paul on December 16, 2011, 07:06:33 PM
when the virtual gamepad IS enabled, banjo tooie wont load
That definitely sounds like it accessing the wrong area of memory.  Sounds like the more stuff thats loaded in memory, the worse it behaves.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 16, 2011, 07:22:23 PM
Ok, those bugs are fixed.

Final Alpha, RC2 (http://www.paulscode.com/source/Mupen64Plus-AE/16DEC2011/Mupen64Plus-debug-final-alpha2.apk)
Title: Re: Alpha Testing Underway!
Post by: SpawnHyuuga on December 16, 2011, 07:45:45 PM
Thanks for the latest download Paul. I'll give it a test run, and we'll see how it runs on my Admire. Many thanks for even trying to make a '64 emulator for ARMv6 devices.
Title: Re: Alpha Testing Underway!
Post by: tgwaste on December 17, 2011, 12:15:48 AM
Latest build working great on my ICS Galaxy Nexus.  Except Zelda seems even slower on it. :(
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on December 17, 2011, 01:01:40 AM
The auto frameskip setting helps with banjo tooie alot. It works better in this version than previously :D

Does ist run at reasonable speed for you ?
With auto fs, I have only under 10 fps ingame.( libgles2n64 )
Manual fs higher than 2 caused black screen or resume on my tegra tablet.
On the other site, even with the more resource hungry rice plugin, the SGS2 performs best.
I've the feeling, the gui eats a lot of power. It semmds many games, that run good on nongui have problems now on tegras.

Hopefully Paul can sort out these problems.  :(
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 01:16:31 AM
I don't see how the GUI would make games any less compatible unless they are trying to access areas of memory they shouldn't be (which is what Banjo Tooie appears to be doing).  The GUI is turned off and gone when you are in-game (other than it using more memory for the static Java components, which shouldn't even affect performance).  I made a couple minor changes to the core, I am calling the frame-skip method on each run, and I'm loading the .so libraries dynamically rather than statically from Java.. personally I'd be more likely to point the blame at one or more of those changes instead.

--EDIT-- I should also point out that with FPS, Accurate N64 Stick, and the "Analog" virtual gamepad layouts which are now enabled by default could also slow you down on lower-end devices or higher-end games.  Do you get more reasonable speed (on Zelda for example) by selecting a "Touch" layout and turning off those two features?

--EDIT2-- Just to show that the GUI is completely turned off in-game, and not even running behind the SDL Surface, here is the code that launches the game (you can see that everything is shut down with "finish()":
Code: [Select]
        else
        {
            Globals.chosenROM = menuOption.info;
            MenuActivity.mupen64plus_cfg.save();
            MenuActivity.InputAutoCfg_ini.save();
            MenuActivity.gui_cfg.put( "LAST_SESSION", "rom", Globals.chosenROM );
            MenuActivity.gui_cfg.save();
            SDLActivity.resumeLastSession = false;
            Intent intent = new Intent( this, SDLActivity.class );
            intent.setFlags( Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP );
            startActivity( intent );
            if( MenuActivity.mInstance != null )
            {
                MenuActivity.mInstance.finish();
                MenuActivity.mInstance = null;
            }
        }
        finish();
And here is the code that runs when you leave the game (you can see that the game is shut down with System.exit and an intent to start a new instance of the menu is sent):
Code: [Select]
            case MAIN_MENU_ITEM:
                saveSession();
                notificationManager.cancel( Globals.NOTIFICATION_ID );
                Intent intent = new Intent( mSingleton, MenuActivity.class );
                intent.setFlags( Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP );
                startActivity( intent );
                System.exit( 0 );

The only part of the GUI that's running in-game is the virtual gamepad.  That's the most likely culprit for speed reduction, IMO.
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on December 17, 2011, 04:12:31 AM
I realy trust in your knowledge and maybe I shouldn't compare the actual state of your emulator with " the other emulator ".
But on this, it is not such a big difference in performance and compatibility between my Tegra 2 devices (phone and tablet) and my SGS2.

But hey, I like your project and it's "only" an alpha release.  ;)

To answer your question. To set/disable your recomended options, it makes not a big difference in performance.
Maybe the slow downs are related in bad Tegra performance and higher resolution of the tablet at this state ?
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 06:19:21 AM
Do you mean it is slower compared to N64oid, or compared to the version prior to adding the GUI (or both)?  As far as N64oid, there are several reasons AE is slower.  The main one is that Yongzh has removed the SDL layer, which adds some overhead.  I fully expect someone will put together a version of this project without SDL (I might even do it myself at some point).  However, the "official" version of this project will keep SDL, because that is too major of a change from the original Mupen64Plus project, and will make contributing back to it a lot more difficult.  I'm even a little concerned that I had to upgrade to SDL 1.3, but I feel like adding in a compiler option to use 1.2 or 1.3 is one way I can contribute back to the original project (since 1.3 is the only version supported on most of the new ports of SDL which will eventually phase out 1.2 over time).

Besides SDL, there are a few other things that make AE slower than N64oid.  The next big one is the virtual gamepad.  From what I've been told (although I can't say for sure since it's closed source), Yongzh is implementing his through GLES calls, while I am using the Android API (which is painfully slow at drawing graphics).  If you are curious about how much this affects performance, compare the performance between different gamepad layouts and with having it disabled.  I do plan to do the same with my virtual gamepad at some point (I've put it off in hopes that this project will pick up a good GLES developer who is willing to tackle it, since I'm not the greatest when it comes to anything GL related)

Another performance difference with N64oid is the video plug-in.  Even if comparing with older versions of N64oid that had gles2n64, it is still very likely Yongzh had a few optimizations in there that he didn't post in the version he put on SourceForge (I've already demonstrated beyond any doubt that he made at lease SOME changes to it without posting the source code, but we can only speculate how extensive those changes were).  It is clear from looking at the source code he did post, however, that he is skilled with assembly language, and has almost certainly added a considerable number of optimizations throughout his closed-source video plug-in as well.  A developer with some assembly skills would be a good addition to the project (hopefully one or two decide to contribute).  Sadly, I completely suck at assembly all together.

Another difference with N64oid is that it is released as a production build, which has some optimizations for speed, such as zip-alignment.  I have been posting AE in debug builds, because it makes problems considerably easier to debug (logcat output is much more useful).  I don't know how much this affects performance, but I'm sure it has at least a small affect (the market release will not be a debug build, and I'll have both versions posted here starting with the first Beta tests).

Ultimately, the performance differences between N64oid and AE are due to a lot of little things which add up to a big thing weighted in favor of N64oid.  I fully expect the scales to become more balanced as time goes on, but N64oid will most likely always be faster, because this project is open-source and his is not (so he can take advantage of optimizations that developers make over here, but not vice-versa).  So moral of the story:  you get what you pay for.  Fork out the 5 bucks (or whatever he's charging these days) to get an emulator that performs better, or use the free and open-source one and help make it perform better yourself.  :D
Title: Re: Alpha Testing Underway!
Post by: SpawnHyuuga on December 17, 2011, 06:28:43 AM
I'm quite impressed with the project, and I'll still look forward to watching it grow. I'm hoping the best for Mupen64+ AE; and that maybe another Dev can be found. I'm sure you'll find somebody willing to help once it goes to the market / Slide. After adjusting some options I was able to max out at about 20 FPS, but I think maybe I'll try messing around a little bit more. Soon my phone will have Overclock, so maybe that will help too; just a shame that a decent phone like the Admire has such low RAM.
Title: Re: Alpha Testing Underway!
Post by: maciek9971 on December 17, 2011, 10:11:59 AM
On my Xperia X10 mini pro Super Mario 64 is working with 5 to 15 fps in game (frame skip 2). I would be happy if in future N64 games works in 25-30 fps, but in this early version this is already huge success.
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on December 17, 2011, 10:28:49 AM
Quote
Do you mean it is slower compared to N64oid, or compared to the version prior to adding the GUI (or both)?

Maybe it's just my misleading imagination.  :-\

And many things have changed in the last months.

- N64oid has gotten many impovements. better speed, more accurate audio and the new graphic plugin.
- you add rice plugin
-  rice performes bad on tegra, but very good on exynos
- the galaxy s2 has many problems with gles2n64, but on rice some games don't start.
- the actual version of rice fixed many things for my SGS2 ( now background and menue textes on bug's life, no flickering in bluesbrothers), but breaks other things ( no gras in conker. before it was only flickering)

at this stage, it's nearly impossible to compare the same settings on different devices.  :(
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 11:12:46 AM
That's true, any of a number of things can make comparisons difficult.  I think the best thing moving forward will be to have the philosophy "what can be done to improve performance?", and see where that leads.  There are currently a LOT of answers to that question ;D  I tend to focus on the question "what features can I add", which may not be the best thing to be spending time on, when there are more immediate performance and compatibility issues to be solved.  Obviously, both can be done at the same time, but perhaps performance should get the majority of the time and effort for a while.
Title: Re: Alpha Testing Underway!
Post by: neo3 on December 17, 2011, 11:14:26 AM
I tested the latest release on my Galaxy Ace and also gave a speed of less than 10 fps, even turning off the sound, which in my opinion made ​​no difference in speed.

The frameskip, if I put more than 2, the game gets a white screen and not come out.

But the emulator is getting very good,  for me opening the Mario 64, is already great.

Congratulations for the great work!
Title: Re: Alpha Testing Underway!
Post by: louCipher on December 17, 2011, 11:54:52 AM
Okay, just tried out the new test build.  Overall it looks good. I'm running a G2 with CM7 (one of the more recent nightlies), and I'm oc'd on-demand to 1.5GHz.  I was running Mario at a steady 30fps. The one issue I did notice had to do with mapping hardware keys.  I like to map Z to my volume up button (it's right under my left ring ringer).  That works, but the problem is, it still functions as the volume up button, so every time I long jump, the volume goes up.

I'll test later at stock speeds and let you know how it performs.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 12:39:33 PM
I like to map Z to my volume up button (it's right under my left ring ringer).  That works, but the problem is, it still functions as the volume up button, so every time I long jump, the volume goes up.
Be sure to check the option "disable volume buttons" in the input settings menu.  Let me know if that doesn't work.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 01:24:23 PM
Requesting Youtube video-showcase submissions.  I will choose one to be placed in the item description when I post it on the Android market.  I want a separate video for the Xperia Play version (which I will be posting soon), so anyone without an Xperia Play is encouraged to submit a video for consideration.  Sadly, I don't have a good video camera, so I can't really do one myself.  Thanks in advance!
Title: Re: Alpha Testing Underway!
Post by: koekje on December 17, 2011, 02:57:55 PM
@ louCipher: i have the same phone. If the volume button doesnt work, try the camera button it works great :p
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 03:34:06 PM
I finished building the Xperia Play version.  As usual, it took a little "blind development" since I don't actually own an Xperia Play  :'(  Quite a few things changed since the last Xperia Play test I put together, so I fully expect it to require some debugging to get it working properly:

Xperia Play, Final Alpha Test (http://www.paulscode.com/source/Mupen64Plus-AE/17DEC2011/Mupen64Plus-debug-xperia-play.apk)   (source code (http://www.paulscode.com/source/Mupen64Plus-AE/17DEC2011/mupen64plus-SDL1.3-xperia-play-source.7z))

For new arrivals to the forum, this version is specifically for the Xperia Play, so if you have a different phone, this is not the version you want to install (see the first post in this thread for more information).
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 17, 2011, 04:52:00 PM
testing it now. i will post the results.
Edit: ok so it appears the analog stick works fine but the right touchpad mapped to the c-stick doesn't appear to work anymore.
Edit2: Also, i have a suggestion that would be nice, a way to un map keys other than mapping to something like search or volume
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 17, 2011, 05:18:40 PM
Requesting Youtube video-showcase submissions.  I will choose one to be placed in the item description when I post it on the Android market.  I want a separate video for the Xperia Play version (which I will be posting soon), so anyone without an Xperia Play is encouraged to submit a video for consideration.  Sadly, I don't have a good video camera, so I can't really do one myself.  Thanks in advance!

I wont be able to make any videos until monday unfortunately. Is there any specific things you would want in the video or do you just want me to do a review type thing?
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 06:03:48 PM
ok so it appears the analog stick works fine but the right touchpad mapped to the c-stick doesn't appear to work anymore
Thanks, I'll look into this.

Also, i have a suggestion that would be nice, a way to un map keys other than mapping to something like search or volume
You can use the menu key to unmap buttons.

Is there any specific things you would want in the video or do you just want me to do a review type thing?
Anything you think will look good to show of the emulator.  Thanks!
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 06:40:54 PM
Ok, please provide the logcat after running the following app and pressing on the right pad c-buttons:

Xperia Play, Touchpad Bug (http://www.paulscode.com/source/Mupen64Plus-AE/17DEC2011/Mupen64Plus-debug-xperia-play2.apk)
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 17, 2011, 07:01:36 PM
Enjoy
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 07:18:32 PM
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.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 17, 2011, 07:24:50 PM
I updated the logcat on my previous post
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 07:35:00 PM
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.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 08:23:45 PM
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 (http://www.paulscode.com/source/Mupen64Plus-AE/17DEC2011/Mupen64Plus-debug-xperia-play3.apk)
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 17, 2011, 09:04:25 PM
Here
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 09:05:41 PM
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.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 09:19:10 PM
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!
Title: Re: Alpha Testing Underway!
Post by: Paul on December 17, 2011, 09:35:03 PM
Ok, this should be the right one..

Xperia Play, RC2 (http://www.paulscode.com/source/Mupen64Plus-AE/17DEC2011/Mupen64Plus-debug-xperia-play4.apk)

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.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 17, 2011, 10:19:40 PM
Sounds good. If you make a donate version I WILL buy it
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 18, 2011, 05:40:48 AM
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.

Title: Re: Alpha Testing Underway!
Post by: Paul on December 18, 2011, 06:17:41 AM
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.
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on December 18, 2011, 06:40:31 AM
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 ?
Title: Re: Alpha Testing Underway!
Post by: Paul on December 18, 2011, 06:52:16 AM
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)?
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on December 18, 2011, 07:12:04 AM
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.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 18, 2011, 07:14:20 AM
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 :)
Title: Re: Alpha Testing Underway!
Post by: FuzzieBoy on December 18, 2011, 07:14:45 AM
Hey, amazing work here!
Just wondering, does it use the phones vibrate function as a vibrator pack? I just think this would be a really nice feature (if it doesn't already). Obviously focus on getting bugs out of the way before adding this, but if this already is in, that definitely makes this the best n64 emulator for the Xperia play!
Title: Re: Alpha Testing Underway!
Post by: Paul on December 18, 2011, 07:21:57 AM
Ok, here is a verbose test to run, scorpio16v.  You will need to manually set first_run=1 in the [GENERAL] section of gui.cfg (it is in the folder [sdcard]/Android/data/paulscode.android.mupen64plus/data/).  Or alternately you could just delete the app data to let the app re-download it again for you.

For the test, please run the app, go directly to "Open ROM" and choose your ROM.  Then from the game, choose "Close" from the in-game menu without going back to the main menu.  Please post the logcat after doing all that:

First-Run Verbose Test (http://www.paulscode.com/source/Mupen64Plus-AE/18DEC2011/Mupen64Plus-debug-firstrun.apk)


Just wondering, does it use the phones vibrate function as a vibrator pack?
Not yet, but I will add this at some point.  One of those things on the ever-increasing "to do" list  ;D
Title: Re: Alpha Testing Underway!
Post by: FuzzieBoy on December 18, 2011, 07:28:24 AM
well, good luck with getting rid of all the bugs, and finishing that ever extending to do list ;) Also, when this does go on the market, I will definitely buy it! Could someone tell me if Conkers Bad Fur Day is playable on the Play with this emulator? I know it is possibly the most advanced game on the n64, so I don't really expect it to be, but if it is, that's one helluva achievement!
Title: Re: Alpha Testing Underway!
Post by: Paul on December 18, 2011, 07:34:52 AM
It should run, but it will be extremely slow and not really playable because it requires the incomplete gles2rice plug-in (gles2n64 has serious graphics glitches).  Gles2rice will improve over time, so I expect Conkers to be playable at some point in the future.  It is almost playable now if I overclock my phone, disable the audio, use the no-sound RSP plug-in, and turn off the virtual gamepad (using my classic Wiimote for input).  It is still a bit too slow to play comfortably (and besides, the best part of Conkers was the audio anyway!)
Title: Re: Alpha Testing Underway!
Post by: FuzzieBoy on December 18, 2011, 07:38:56 AM
It should run, but it will be extremely slow and not really playable because it requires the incomplete gles2rice plug-in (gles2n64 has serious graphics glitches).  Gles2rice will improve over time, so I expect Conkers to be playable at some point in the future.  It is almost playable now if I overclock my phone, disable the audio, use the no-sound RSP plug-in, and turn off the virtual gamepad (using my classic Wiimote for input).  It is still a bit too slow to play comfortably (and besides, the best part of Conkers was the audio anyway!)
Definitely! What's the point of Conkers Bad Fur Day if you can't listen to the great mighty poo song :P
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 18, 2011, 07:50:11 AM
I done a video demonstrating/talking about the emulator and im transferring it to my computer. I hope its good enough and I hope my funny accent doesn't matter :P

Heres the video: http://www.youtube.com/watch?v=dpkeqLopaI0

Its unlisted for now to see if you think its ok before I make it public.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 18, 2011, 10:48:53 AM
I done a video demonstrating/talking about the emulator and im transferring it to my computer. I hope its good enough and I hope my funny accent doesn't matter :P

Heres the video: http://www.youtube.com/watch?v=dpkeqLopaI0

Its unlisted for now to see if you think its ok before I make it public.
I like it. Your lucky to have the UK version of the play and also nice using a gamecube as a camera stand  ;D
Title: Re: Alpha Testing Underway!
Post by: Paul on December 18, 2011, 10:49:40 AM
The wrong skin error didn't appear with the verbose test. The analog tablet skin was set correctly.
Nevertheless, I'll add the logcat.

http://db.tt/WkWSXtCb
Thanks, I think I fixed the problem when I fixed a different earlier one.  Please try this version and let me know if it has the problem (this is the one I'm planning on putting on the market, so I need to make sure it is in there):

First Beta Test (http://www.paulscode.com/source/Mupen64Plus-AE/17DEC2011/Mupen64Plus.apk)

As before, make sure the first_run is set to 1, or delete the app data before testing.
Title: Re: Alpha Testing Underway!
Post by: scorpio16v on December 18, 2011, 11:01:36 AM
The beta runns fine with the right settings. I have deleted the app-data and I must even uninstall the former version.
Without that, it aboards the install. (something with wrong signature).

I've edited my other post with a question, related to sound.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 18, 2011, 11:12:06 AM
I done a video demonstrating/talking about the emulator and im transferring it to my computer. I hope its good enough and I hope my funny accent doesn't matter :P

Heres the video: http://www.youtube.com/watch?v=dpkeqLopaI0

Its unlisted for now to see if you think its ok before I make it public.
I like it. Your lucky to have the UK version of the play and also nice using a gamecube as a camera stand  ;D

Haha I was waiting for somebody to notice that :)

I was looking around for something to balance my iphone on to take the video and the first thing I saw was the gamecube, Its the tallest console I own. :P

Title: Re: Alpha Testing Underway!
Post by: Paul on December 18, 2011, 11:21:27 AM
Excellent video.  I'll use it for both versions on the market for now.  I can always change it later if someone with a different device submits another good promotional video to use for the non-Play version.  Also, I should be able to change the screen shots if anyone comes up with a good one they would like to see listed, and can add or edit stuff in the description if anyone has suggestions for that as well.  I like the idea of making it a community effort rather than seeming like I am the sole owner of the project.
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 18, 2011, 11:27:05 AM
Excellent video.  I'll use it for both versions on the market for now.  I can always change it later if someone with a different device submits another good promotional video to use for the non-Play version.  Also, I should be able to change the screen shots if anyone comes up with a good one they would like to see listed, and can add or edit stuff in the description if anyone has suggestions for that as well.  I like the idea of making it a community effort rather than seeming like I am the sole owner of the project.

And thats why this emulator is my favorite one so far. Its awesome how interactive you have been with the community!

Also my xperia play has been updated to 2.3.4 so I can take screenshots without root access now so I can take images of any games you want.

Thanks for using the video btw, the quality isnt that good and im not really good at talking in front of a camera but I like to try and help. :)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 18, 2011, 11:27:34 AM
Xperia Play, First Beta Test (http://www.paulscode.com/source/Mupen64Plus-AE/17DEC2011/Mupen64Plus-xperia-play.apk)

Here is the Xperia Play version I'm planning to post on the market.  Could you please test it and make sure it is the correct version (with the c-buttons fixed)?  After last night, I want to be sure, haha!
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 18, 2011, 11:37:07 AM
I could not update it directly, i had to uninstall it first  :P
but other than that, it seems to work fine
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 18, 2011, 11:41:47 AM
Xperia Play, First Beta Test (http://www.paulscode.com/source/Mupen64Plus-AE/17DEC2011/Mupen64Plus-xperia-play.apk)

Here is the Xperia Play version I'm planning to post on the market.  Could you please test it and make sure it is the correct version (with the c-buttons fixed)?  After last night, I want to be sure, haha!

I tried it just now and the touch pads seems to work correctly just like they did in the previous build I tried. Should I delete my app data to double check?

Also heres some screenshots I took, you dont need to use them all just pick any ones you might like. :)
http://dl.dropbox.com/u/13594612/paulscode/pics/screenshot_2011-12-18_1730.png
http://dl.dropbox.com/u/13594612/paulscode/pics/screenshot_2011-12-18_1732_1.png
http://dl.dropbox.com/u/13594612/paulscode/pics/screenshot_2011-12-18_1732.png
http://dl.dropbox.com/u/13594612/paulscode/pics/screenshot_2011-12-18_1733.png
http://dl.dropbox.com/u/13594612/paulscode/pics/screenshot_2011-12-18_1735.png

I can take screenshots form other games too if you want, Or I can take pics without the touch buttons.
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 18, 2011, 11:42:44 AM
i like the first and last pics the best
Title: Re: Alpha Testing Underway!
Post by: Paul on December 18, 2011, 11:44:44 AM
It might be good to get some without the virtual gamepad visible, for the Xperia Play listing (want to show that they aren't always visible, although the video shows that as well).  I'll use the first and last image in the listing.
Title: Re: Alpha Testing Underway!
Post by: Paul on December 18, 2011, 11:54:20 AM
I could not update it directly, i had to uninstall it first  :P
but other than that, it seems to work fine
That's because it has a different signature (the tests had a debug signature, and these have my official paulscode.com digital signature on them).  It conflicts because they have the same Android package name.  In the future, I'll make sure the tests have a separate package name (and icon!) than the market release, so testers can have both installed at the same time.

I tried it just now and the touch pads seems to work correctly just like they did in the previous build I tried. Should I delete my app data to double check?
Oh, no, if the C buttons work, it is the latest version.  Main reason I asked rather than just rebuilding it again to be sure, is because you have to go through some hoops to get a proper release version, signed, and aligned, which is a bit of a hassle.

wow paul getting ready for the market! I still remember you saying woohoo i can see mario! :p anyway with the latest version i wanted to put my camera button as Z button but it would work :/
I'll put together a verbose test for you to run (I need to figure out the package thing first, which I'll do as soon as I finish writing up these market listings.)
Title: Re: Alpha Testing Underway!
Post by: xperia64 on December 18, 2011, 11:56:24 AM
I take it the lastest beta has most of the verbose output removed? Because banjo tooie is not crashing when it changes scenes anymore ;D ;D ;D
Title: Re: Alpha Testing Underway!
Post by: Epic_bubble on December 18, 2011, 11:59:39 AM
Some more images:

(http://dl.dropbox.com/u/13594612/paulscode/pics/Photo%2018-12-2011%2005%2056%2000%20PM.jpg)
(http://dl.dropbox.com/u/13594612/paulscode/pics/screenshot_2011-12-18_1759.png)
Title: Re: Alpha Testing Underway!
Post by: Paul on December 18, 2011, 12:57:00 PM
BTW, I am locking this thread to encourage folks to use the new boards I set up.  I'll still answer any questions on here that have already been posted, after splitting them off into new topics.