Author Topic: 3.0 Alpha Testing  (Read 261010 times)

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: 3.0 Alpha Testing
« Reply #30 on: December 07, 2014, 10:12:32 AM »
I pushed the fix.

RefMD5 is already taken care of in RomDetail.  See the comments in the code.  A truly unknown game is one without any MD5 or CRC reference anywhere in mupen64plus.ini.  So there's basically nothing that can be inferred about the game other than its filename and its header.

If lookupByMd5 returns null and lookupByCrc returns multiple entries, that means that the MD5 cannot be found anywhere in the ini file (neither the md5 key nor the refMd5 field).
« Last Edit: December 07, 2014, 10:16:40 AM by littleguy »
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline xperia64

  • Moderator
  • double
  • *****
  • Posts: 591
    • View Profile
    • My Apps
Re: 3.0 Alpha Testing
« Reply #31 on: December 07, 2014, 10:47:53 AM »
Good, also, can you create a .no media file in the GalleryData folder? Don't want the covers in my pictures

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: 3.0 Alpha Testing
« Reply #32 on: December 07, 2014, 10:57:23 AM »
Good idea, never knew about that.  Should we keep save-related screenshots out as well?  What about user-generated screenshots (manual screenshots)?

http://android2know.blogspot.com/2013/01/create-nomedia-file.html
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3491
  • Developer
    • View Profile
    • PaulsCode.Com
Re: 3.0 Alpha Testing
« Reply #33 on: December 07, 2014, 11:11:55 AM »
If lookupByMd5 returns null and lookupByCrc returns multiple entries, that means that the MD5 cannot be found anywhere in the ini file (neither the md5 key nor the refMd5 field).

Ok, I have been looking through this part of the code to get better familiar with the process.  Just to follow the logic through a make-believe scenareo (to make sure I understand it correctly -- point out if I get things wrong)

1) I hack a small piece of my Mario64 ROM, so that the MD5 changes from 20B854B239203BAF6C961B850A4A51A2 to something else I'll refer to as [XXX..], but CRC remains the same: 635A2BFF 8B022326.  (other scenarios this could might happen is if some unusual procedure is applied to alter the data of an otherwise-recognizable ROM, as xperia64 mentioned, or if I pick up some extra junk data when I am dumping my ROM, as currently is the case of my other project)

2) The new MD5 [XXX..] is now nowhere in the ini file, but the CRC is in the ini file 5 times under various other MD5s for Mario64 ROMs, all of which have the RefMD5 of 20B854B239203BAF6C961B850A4A51A2.

3) The app finds the ROM file, and lookupByMd5 fails because [XXX..] is unique and unrecognized.

4) The app then runs lookupByCrc, and finds 5 matches.   Logic uses the "assumed MD5" from RefMD5 of the first match, which in this case is 20B854B239203BAF6C961B850A4A51A2



So if I am on the right page, there are a couple scenarios left to resolve:

1) If there are more than one match on CRC and the first match doesn't have a RefMd5, then the logic doesn't know which section to use.

2) If neither the MD5 nor the CRC are recognized, then the logic doesn't know which section to use.



One possible solution (let me know if this jives with the process or not), would be to create a second ini file (I'm pretty sure I recall reading about this on here a while back, so not trying to sound like I came up with that idea myself).  Process would work something like this:


1) Try to find the ROM by MD5 in the default ini file first

2) If not found, try finding the ROM by MD5 in the second ini file

3) If still not found, try finding the ROM by CRC in the default ini file

4a) If found and has only one match, create a new entry in the second ini file with the new MD5 and values cloned from the match.

4b) If found, and has a RefMd5, create a new entry in the second ini file with the new MD5 and values cloned from the RefMD5 entry.

4c) If found, and does not have a RefMd5, create a new entry in the second ini file for the new MD5 and some default values

4d) If not found period, create a new entry in the second ini file for the new MD5 some default values
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: 3.0 Alpha Testing
« Reply #34 on: December 07, 2014, 11:26:31 AM »
Let me read through this carefully and respond after lunch.  But I want to point out one quick thing.

refMD5 in mupen64plus.ini is not important; it's just an internal mechanism used by the core to keep the ini file smaller and easier to maintain.  That's why it's not even stored as a field in RomDetail (see the comments in the constructor).  It is theoretically possible that two entries in mupen64plus.ini have the same CRC and neither contains a refMD5 field that refers to the other.  The true, calculated MD5 of the ROM is the unique key that matters.

Edit: Please pull the latest.  I renamed something in the front's rom info cache to avoid confusion.
« Last Edit: December 07, 2014, 11:28:50 AM by littleguy »
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3491
  • Developer
    • View Profile
    • PaulsCode.Com
Re: 3.0 Alpha Testing
« Reply #35 on: December 07, 2014, 11:29:37 AM »
Latest build:

Alpha 3 (Fix some games not selectable from gallery)


refMD5 in mupen64plus.ini is not important; it's just an internal mechanism used by the core to keep the ini file smaller and easier to maintain.  That's why it's not even stored as a field in RomDetail (see the comments in the constructor).  It is theoretically possible that two entries in mupen64plus.ini have the same CRC and neither contains a refMD5 field that refers to the other.  The true, calculated MD5 of the ROM is the unique key that matters.

Agreed, which is one argument for always creating a new entry (in a second ini file for example) when an unrecognized MD5 is encountered.  The RefMD5 would only be used for guessing initial values (we would need to provide a UI for the user to change them, since the assumption could be wrong).
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3491
  • Developer
    • View Profile
    • PaulsCode.Com
Re: 3.0 Alpha Testing
« Reply #36 on: December 07, 2014, 11:43:09 AM »
Please pull the latest.  I renamed something in the front's rom info cache to avoid confusion.

Alpha 4 (Rename some things in ROM info cache to avoid confusion)
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3491
  • Developer
    • View Profile
    • PaulsCode.Com
Re: 3.0 Alpha Testing
« Reply #37 on: December 07, 2014, 11:53:20 AM »
refMD5 in mupen64plus.ini is not important; it's just an internal mechanism used by the core to keep the ini file smaller and easier to maintain.


Ah, yes, I see.  Basically says "use all the settings from that section, plus these here in this section".  In that case, I would change my above recommended process a tad:


1) Try finding the ROM by MD5 in the second ini file first (checking this first would allow us to eventually provide an option to override default settings and easily "undo" them)

2) If not found, try to find the ROM by MD5 in the default ini file second

3) If still not found, try finding the ROM by CRC in the default ini

4a) If found and has only one match, create a new entry in the second ini file with the new MD5 and values cloned from the match.  If the one match has a RefMD5, use combined settings from both -- do not add a RefMD5 to the new entry (will allow user to customize all the settings)

4b) If found and has multiple matches, create a new entry in the second ini file with the new MD5 and values cloned from the first match, combined with settings from RefMD5 section if present -- do not add a RefMD5 to the new entry (will allow user to customize all the settings).

4c) If not found period, create a new entry in the second ini file for the new MD5 and some default values




-- EDIT--

BTW, the reason I recommend making a "best guess" about which section to use and allowing the user to change it later, is because most of the time, the best guess will be enough to get the average user up and playing (and not requiring them to make a selection they probably won't understand anyway).  Advanced users will be smart enough to select what they want later.  Any problems created for average users due to incorrect "best guess", they will come here and we can assist them in selecting the right settings.

-- EDIT 2 --

Also, to save time when launching the game, we really wouldn't need to merge the two ini files.  Instead, we could just output a small ini file with only the one entry for the game being launched.  This could also be applied to cheats.  We know what game is about to be launched, so no need to pass the core huge files with data for all possible games.
« Last Edit: December 07, 2014, 12:21:55 PM by Paul »
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline Jermain

  • byte
  • *
  • Posts: 18
    • View Profile
Re: 3.0 Alpha Testing
« Reply #38 on: December 07, 2014, 11:56:10 AM »
Alpha 4

exiting game crashes everything

Roms in Zip files "load" now, but doesn't play...

Thank you.


Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: 3.0 Alpha Testing
« Reply #39 on: December 07, 2014, 12:33:49 PM »
On my FireTV,a romhack titled "Super Irishly Drunk Giant Waluigi 64" opens and runs properly.

Also,a Zelda Debug romhack called Voyager runs,but still freezes on exiting the pause menu when using Rice.
It does not freeze in Glide normally,maybe the original debug rom also freezes in the same way.
Garbage data in the pause menu background is similar to Smash Bros. also seen with Rice.
Again,Rice is running faster when it can,but now struggles more with lag in heavy rendering views.

Glide64 is suffering with black texture spots with characters from character select on Super Smash Bros. via the Alpha.
It does not happen on Gillou's latest build since last time I checked. (going to check again brb)

Edit:Crash after game exit again with Smash Bros. on latest alpha,about to check Glide64 now.

Edit2:No black texture,but it got the bright flashing glitch with Super Smash Bros. this time.
« Last Edit: December 07, 2014, 12:47:42 PM by retroben »

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: 3.0 Alpha Testing
« Reply #40 on: December 07, 2014, 12:54:52 PM »
DP

Glide64 is also horrendously slow on the alpha with Super Smash Bros.,even with "read every frame" disabled,which is a major issue.

My Intel tablet did not get a crash with Super Smash Bros. when exiting it this time.
FireTV crashed every single time when exiting that game.

Edit:It must like my Intel because it is not lagging on it in that way.
First run had invisible elements like it usually does when switching plugins,but secondary run in different session looks fine.

Something was botched for ARM since it lags on my FireTV compared to Gillou's build not lagging.

Edit2:It is now letting me hit the device's back button to get out of the game settings after exiting a game.
« Last Edit: December 07, 2014, 01:15:39 PM by retroben »

Offline Zaneris

  • byte
  • *
  • Posts: 39
    • View Profile
Re: 3.0 Alpha Testing
« Reply #41 on: December 07, 2014, 01:52:52 PM »
Alpha 4:

All games load just to a black screen, regardless of core selected.

DK64 has .zip at the end of the name. (only rom that does this)

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: 3.0 Alpha Testing
« Reply #42 on: December 07, 2014, 02:47:50 PM »
The zip extraction needs to be re-inserted IIRC.  Xperia64 had implemented that on a separate branch; it should be cherry pickable.  See my fork of mupen64plus-ae.

@Zaneris - What do you mean "all games load to black screen" and "dk64 is only rom that does this"?
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Zaneris

  • byte
  • *
  • Posts: 39
    • View Profile
Re: 3.0 Alpha Testing
« Reply #43 on: December 07, 2014, 02:57:01 PM »
The .zip DK64 title. http://i.imgur.com/0WRgDOL.png

And black screen on loading games. http://i.imgur.com/EgyXuwdh.jpg

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: 3.0 Alpha Testing
« Reply #44 on: December 07, 2014, 03:10:22 PM »
Note to testers A LOT HAS CHANGED IN THE FRONT-END for the alpha version.  Most settings are now encapsulated into "profiles".  This allows you to "set and forget" settings for a game, and they will always be used regardless of the settings for a different game.

If you were using frameskip before, you should use one of the "Speed" emulation profiles.

Also, in case of crashes, try Restart (not Resume) from the Play menu.  This is especially important when updating to a different alpha release.

We need to get this "Gilles' build" on the forum, along with the commit reference to the source code.  Continual comparisons to something I don't have is completely unhelpful.

BTW hyperboles like "botched" and "horrendous" are loaded with emotion that is easy to misinterpret.  Better to simply say "broken", "crashes", "black screen", "slower than [some other build]", etc.  Keep it factual please.
« Last Edit: December 07, 2014, 03:12:30 PM by littleguy »
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version