Brainstorming Version 3.0

[littleguy]

@Paul - To download cover art, we'll need the ROM's "good name" in the Java code.  Which requires computing the MD5 checksum and looking it up in mupen64plus.ini.  We could write another JNI function that calls some functions in the core...

...but out of curiosity I tried doing it entirely on the Java side.  Turned out to be really easy with the ConfigFile class and the Apache commons-codec library.  The catch is that it adds a 258KB jar file to the APK.  Still, the ease of maintenance and the decoupling from the core might be worth it.  Thoughts?

Either way, it works well at least in the short term for prototyping.  I'm attaching the source in case you want to use it.

[littleguy]

Been working on the auto-cover-download machinery.  Having the "goodname" of the rom helps, but isn't a surefire way to construct the correct weblink.  So far I've only tried downloading the cover art from here, and the filenames don't always match up easily to the goodnames.

This is just a debugging screen, but you can see right now I'm missing most of the cover art.  The text below each cover is [goodname][crc][md5] in case you're wondering.

[gdark100]

littleguy - this site has a LOT of hires box images, for most n64 titles. Unfortunately, the names are abbreviated. 
http://64dd.net/modules/games/index.php?system=n64&type=released&show=alphabet&value=0-9&sort=title&order=asc

[xperia64]

the problem is, it appears most of these sites have the images and such, but no publicly accessible database like there is for wii and gamecube games.

[littleguy]

@Paul - What do you think about just copying the cover files off the Daedalus repo and putting them somewhere we control.  Easiest might be just a folder in the git repo, files could then be downloaded via github http website.  Or put them on paulscode.com.  One benefit, besides being in control of the files, is that we could rename some of them so that they match the goodname.  One less hassle to deal with.

[Paul]

Good idea.  I'll set up a repo for the images under paulscode.com.  Of course if Nintendo or other company takes issue, they may need to be taken down (storage of cover art is definitely a legal grey area)

[littleguy]

Alright then.  I'll probably rename a bunch of them so that it's easy to convert from the GoodName in mupen64plus.ini to the weblink.  Maybe I should do that first, then post them somewhere for you to grab.

I noticed wikipedia has cover art and it says it abides by "fair use".  Not sure that applies in our case but FWIW...
http://en.wikipedia.org/wiki/File:Super_Mario_64_box_cover.jpg

[littleguy]

Paul - I may be able to sink some more time into this over the weekend.  But if you want me to slow down or focus on something in particular, let me know.  I don't want to dictate the design just because I happen to be the one with some time right now.  (I'm guessing you're on vacation or really busy this past week.)

[Paul]

No worries, you can work on whatever you like.  We are back from vacation, but trying to meet an impossible deadline for work, so spending pretty much every waking hour on that.  On the flip side I'm learning some very useful new skills (I'm not sure if you are familiar with Symfony2, but it is a pretty awesome architecture - I highly recommend taking a look at it if you are into web development).  The tools suite I am developing has integrated components for web, Android, and iOS.

[littleguy]

Interesting.  Coincidentally I just got assigned a web-development project at work, not something I or my company does much of.  Will have to take a look at that in detail.  Thanks for the pointer.

[RogerSmith]

Been working on the auto-cover-download machinery.  Having the "goodname" of the rom helps, but isn't a surefire way to construct the correct weblink.  So far I've only tried downloading the cover art from here, and the filenames don't always match up easily to the goodnames.

This is just a debugging screen, but you can see right now I'm missing most of the cover art.  The text below each cover is [goodname][crc][md5] in case you're wondering.

Looks good littleguy.

[karl_87]

I've just had a great idea, once version 3 is futher in development, would it be possible to have all the settings per game stored in a text file. This way we can work out the settings for all the games on an ouya for example, and then share the text file with others to create a full master file! Once this has happened, the next step would be to load the master file by default (or even ask the user) if an ouya is detected on first run for example. This would obviously work for other devices but think ouya is a great starting point.

Hope I made sense, what do you guys think?

[Mikhail]

Neat stuff.  So, how/where do you propose we use this?
 1. on the fly enhancement of stock textures
 2. offline enhancement of stock textures, loaded as custom textures at runtime
 3. on the fly enhancement of the final rendered image

I'm guessing you didn't mean option 2, since people already do that outside of mupen and hi-res texture packs already exist.  For options 1 and 3, sounds like this would require some shader programming inside the video plugin, which I'd consider an enhancement that could be done anytime (don't have to wait for version 3).  Not many devs here have the skillset for that however.

Might be worth starting a discussion with the upstream devs, since this would be useful across all platforms, not just android:
https://groups.google.com/forum/#!forum/mupen64plus

I'd go for option 3. using XBR2 noblend.

As for options 1 & 2 not too sure about a texture filter as everything seems to blur pixels so 3d models always look muddy, NearestNeighbour and ReverseAA work best at retaining the likeness as if it was drawn at a higher resolution, tbh i'd rather just use hi-textures instead you can't add detail that was never their in the first place by upscaling so there's no overall benefit .


Also how about about a

option 4: Increasing the internal resolution to it's max then downscaling the final rendered image to your desired resolution, it should theoretically retain the most detail.

[littleguy]

Thanks for all the feedback, guys.

Just an update - I had planned to work on the user interface over the past weekend, but soon realized that the current activity mechanics/lifecycle should probably be cleaned up a bit first.  Gilles noticed some more GL context creation issues, and an increasing number of users are experiencing strange audio latency.  The hard-exit hack (ASDP bugfix) is also long overdue for removal.  These issues might be resolved by updating to the latest revision of SDL2, so I'm tackling that first.  Once the lifecycle/launch mechanics are resolidified, I'll then get back to wiring up the new front-end and updating the user preferences structures.  Don't want the tail (UI) to wag the dog (activity launch mechanics).

I agree, having the game-specific overrides in text files on the sdcard would permit a lot of flexibility.  Besides allowing experts to revise and share configs for games, it would also allow basic users to update the recommended settings between published releases.  For example, we could add these config files to the github repository, and users could have a button to refresh the config recommendations whenever they like.  Clicking the button would just download the text files to a location on their sdcard.  So, at the end of the day, there may be a "refresh" menu in the main gallery screen, with three items underneath it:
 - Refresh game list (searches sdcard for rom files)
 - Refresh recommended config settings (downloads config files from github http server)
 - Refresh cover art (downloads images from some http server)

I can just imagine the average user who opens a github issue to say <obscure game xxx> is buggy; we update the config file on github and tell them to refresh their recommended settings.  Case closed

[littleguy]

3. on the fly enhancement of the final rendered image

I'd go for option 3. using XBR2 noblend.
...
Also how about about
option 4: Increasing the internal resolution to it's max then downscaling the final rendered image to your desired resolution, it should theoretically retain the most detail.

All interesting discussion, though I'm not the person with the skills to implement it.  As for option 4, if I understand you correctly, this is already implemented for the most part.  The current video settings allow you to specify the "rendered resolution" (internal resolution?) independent of the device's actual hardware resolution.  It would be trivial to add higher resolutions to the current list.  However, I don't think that this would make much difference regarding low-res textures; they'd still be muddy.  Maybe a little less pixellated, but still muddy.