Alpha Testing Underway!

[Paul]

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)

[Mats]

gui will be awensome !

[Epic_bubble]

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

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 .

[TFreestone]

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

[Paul]

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

[Paul]

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

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.

[xperia64]

Got it. Didn't work.on xperia play

[scorpio16v]

you are trying to start code in an area where system libarys are located ? 
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

[Paul]

you are trying to start code in an area where system libarys are located ? 
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.

[Paul]

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

[xperia64]

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.

[Paul]

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

[xperia64]

Ok here.

[dustarma]

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*

newbielink:http://dl.dropbox.com/u/28439034/DEBUG_PluginTestA_memoryMaps.txt [nonactive]

here's an alternate link.

[Paul]

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.