Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Paul

Pages: [1] 2 3 ... 12
1
Theory and Discussion / HTM Reinforcement Learning
« on: October 31, 2016, 04:41:31 PM »
One of the important areas that Numenta's implementation of HTM hasn't covered yet is reinforcement learning (RL).  This is because reinforcement learning requires a system that is capable of taking actions based on input (i.e. sensory-motor inference) and that is where Numenta is actively researching.

Numenta's approach to HTM is to refer to neuroscience to understand how the cortex functions, and make their implementations true to their biological counterparts.  While I think this is definitely the correct long-term approach, I am not bound by this requirement for my project.  I have thought out my own HTM-based sensory-motor and RL design.  It is most likely quite different from the biological systems, but should work (based on my current understanding of HTM concepts).

At a high level, the basic idea is to have three high-order sequence memory layers.  The first is a standard temporal memory layer, for learning patterns and context from sensory input.  This layer projects into the second layer.  The second layer receives input from motor commands, and projects into the third layer.  The third layer receives reinforcement input (reward/ punishment).



Each layer's input passes through the usual spatial pooler to select the active columns (i.e. different columns are active in each layer).  Neurons in the first layer are typical, growing distal dendrites connecting to other neurons in the same layer.  The second and third layers are a bit different.  Neurons in the second layer grow distal dendrites connecting to neurons in the first layer.  Similarly, neurons in the third layer grow distal dendrites connecting to neurons in the second layer.



With this setup, the first layer can make inferences about what sensory information will come next based on the current context.  Columns represent the input, and neurons within the columns represent the context.  This is the typical HTM process as implemented by Numenta.

The second layer makes inferences about what motor commands will come next based on the current sensory context.  Columns in this layer represent the motor commands, and neurons within the columns represent the context.

The third layer makes inferences about rewards or punishments that will come next based on the current sensory-motor context from the second layer.  Columns represent the reinforcement, and neurons within the columns represent the context.  How good or bad a particular set of motor commands is in a given context consists of the immediate reward/punishment in that state plus the predicted rewards/punishments of possible next actions.  The system can then take actions based on what it predicts will happen.

Besides rewards and punishments, I have also introduced the concept of "novelty".  These columns represent the level of unknown outcomes a particular action might lead to (i.e. future actions down a particular path that the system has not yet tried).  The purpose of this is to allow the system to explore actions it hasn't tried yet, versus always only ever going with the very first positive action it has done in a particular context.

The system will have a curiosity level that grows over time, and is reduced any time it does something novel.  The more novel a path is, the more the system's curiosity is satisfied.  A combination of novelty score and curiosity level can eventually outweigh punishments that the system has encountered in the past, and cause it to try a particular action again in order to explore subsequent actions down that negative path that it hasn't tried yet (and which could lead to rewards).

2
Mini Projects / HTM Robot Lab
« on: October 25, 2016, 08:00:03 AM »
I have started building out a "robot lab" in which to test several of my theories on basic capabilities that I want to give ARTUR's initial AI before putting it into the transmutation routine.  The lab consists of a robot with four "bumper" sensors, four "thruster" motors, and a maze which can be defined in a simple text array.

So far I've got the maze and robot functioning (just a slight hit detection bug I need to work out).  I've gotten the neurons hooked up for the bumpers, thrusters, and position.  The HTM layers still need to be hooked up.

For now, the robot is simply controlled by the arrow keys.  Obviously the goal is to hook up HTM layers and implement reinforcement learning to have it learn and drive itself to complete the maze.  Lots of potential tests that can be done with this app, so should get pretty interesting.

The WIP app can be accessed HERE.  I'll put up the source code on GitHub once I have finished writing all the remaining basic components.

3
Mini Projects / HTM Piano
« on: October 24, 2016, 04:53:07 PM »
I have looked at various AI technologies, and the most promising in my opinion is Hierarchical Temporal Memory (HTM).  This technology attempts to model aspects of the cortex in a manner which remains true to the biology.  Numenta has a nice collection of resources on GitHub for anyone interested.  The HTM White Paper in particular contains easy to follow pseudo-code, and Numenta's implementation of HTM, called NuPIC is open-source.

As a way of learning HTM, I wrote my own implementation, and used it in THIS SIMPLE DEMO.  After adjusting the properties of the system and clicking "Start", you are presented with a few piano keys and a depiction of the neurons of the "brain".  Click the keys to play notes, and the system tries to predict what note you are going to play next.

It isn't too intelligent, but it was a good start, and I learned a lot from it.  I developed it prior to studying the white paper or looking at NuPIC source code (solving the problems myself helps them to stick, versus starting with the answer).  I have since gone back and studied Numenta's implementation in depth, and I am in the process of rewriting my own implementation.  I will post a link to the source on GitHub once it is complete.

Numenta's implementation of HTM currently is only capable of sequence memory.  I am looking at expanding it to be capable of reinforcement learning and sensory-motor capabilities.  I'm less bound by Numenta's rule to remain true to the biology, so I believe I can use this technology to give ARTUR a good set of basic capabilities prior to plugging it into the transmutation routine.

4
Theory and Discussion / What is ARTUR?
« on: October 24, 2016, 04:10:03 PM »
- This slot is reserved for the project roadmap and links -

5
Announcements / Forum Rebuilt
« on: October 22, 2016, 06:53:30 PM »
I have rebuilt the forum from vanilla SMF 2.0.12 source code, and have re-applied all of my mods and security settings.  Things appear to be running well, but if you notice any problems, let me know.

You will also notice that I have consolidated a lot of the boards in the Mupen64Plus AE category.  This is just to scale down a bit since the initial burst of activity has slowed significantly.  I'll be adjusting the forum further as necessary in the coming days and weeks as I shift focus to my next big project.

6
General Discussion / Bad luck..
« on: June 16, 2016, 07:53:09 AM »
Hey, sorry I have been absent.  The hard drive failed on my computer (again -- this is the second one).  This time I wasn't able to recover any of the data, so I had to start from scratch.

Unfortunately when I went to try and recreate the auto-build environment, I discovered that the Android SDK has changed and the old way of building from the command line needs to be altered (wasn't able to easily find older versions of the SDK -- probably a good time to upgrade anyway).  I've been dealing with some other issues as well, so haven't had a chance to look into this (a run of bad luck, I won't go into now).

I should have some time this weekend to try and get the auto-build system running again.  I'd also like to publish an update to the play store.  I'll need to dig through some system backups to find my signature keys first.

7
General Discussion / Bandwidth Limit Exceeded
« on: January 01, 2016, 10:50:54 AM »
Some of you may have noticed yesterday, that on the last day of December, the monthly bandwidth was exceeded for PaulKnows.Com (which currently only really consists of subdomain paulscode.paulknows.com, which this website PaulsCode.Com is an alias for).  We are receiving enough in Mupen64Plus AE donations to order a higher tier for increased bandwidth, and I have done that (double the previous tier), and we can go even higher if needed.  That said, it might be wise to take the time and analyze the hotspots to determine where the most bandwidth is being consumed, and see if there are ways to reduce bandwidth consumption in those areas.

Here is a breakdown of bandwidth consumption by folder (this is probably the best metric to determine where users are consuming the most data).  I've highlighted some of the interesting areas that are not part of the forum which are consuming bandwidth in the GB's:



Obviously, the AutoBuilds are consuming the highest bandwidth.  Over 19K users in December, consuming over 600 GB of bandwidth.  This could be an area where we can look at reducing bandwidth.  Some options that come to mind are 7-zipping to squeeze a little more compression out of the files (although APKs are already ZIP files, so this wouldn't likely have much effect), or purchasing a separate, cheaper file storage solution.  Another option (which I don't like, but should put it out there for discussion) would be to stream the AutoBuilds (versus posting open links) and make the routes to stream them only available to logged in users on the forum.

Another one of potential concern is the CoverArt folder.  This isn't consuming nearly as much bandwidth as the auto-builds, but I am surprised to see over 37K hits on this folder in one month.  My thought is that there are probably Mupen64Plus AE clones on the market which are using the new gallery UIs, and pulling cover art from our servers.  Another possibility is that various emulation websites or applications are pulling from us simply because we have made the files open to the wide web.  I'm not necessarily opposed to this, but if it becomes such a bandwidth hog that users of the official app are being negatively impacted, we might want to think up a validation system of some type to ensure only our app can pull cover art from our website.  As with the AutoBuilds, a couple other immediate solutions that come to mind are 7-zip and purchasing a separate file storage solution.

The 19 Jan build isn't too surprising, since that is the latest published build of Mupen64Plus AE.  I mainly highlighted it for comparison with the AutoBuilds usage (looks like folks are primarily pulling the latest builds, which is good -- indicates there is still a large community of interest in recent work on the project).

The 23 Dec and 7 May builds are more interesting to me.  I am not sure what makes these two special.  23 Dec is the next-to-last published build, so some of those numbers could be due to regressions, but the numbers are still rather high considering how long it has been since the last published update.  And I really don't see anything unique at all about the 7 May build.  My thought is that maybe there are some outdated links on other websites that are linking back to those files.  It may be possible to free up a little bandwidth by changing the links for those two builds.

I'll be looking at the options some more over the next few days, and let everyone know what I have decided.  If anyone has input on any of my suggestions, or some other ideas for addressing bandwidth consumption, feel free to post.

8
General Discussion / Auto Build Issues
« on: December 30, 2015, 01:09:16 PM »
Starting a thread where we can discuss future issues with the Auto Build script, since problems seem to come up with it fairly often.

Latest problem is with the cheat_editor_ui_redesign branch being built (or possibly another branch/ commit being built which the script believes to be that one).  Below are some examples of the problem, and some of the things I have done to diagnose:

$ git checkout master    (can't check out master after checking out cheat_editor_ui_redesign)
Code: [Select]
error: Your local changes to the following files would be overwritten by checkout:
        res/xml/preferences_global.xml
Please, commit your changes or stash them before you can switch branches.
Aborting

$ git checkout --force master    (but will if I use --force)
Code: [Select]
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

$ git status    (no issues yet)
Code: [Select]
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean

$ git checkout cheat_editor_ui_redesign    (check out cheat_editor_ui_redesign again)
Code: [Select]
Switched to branch 'cheat_editor_ui_redesign'
Your branch is up-to-date with 'origin/cheat_editor_ui_redesign'.

$ git status    (problem seems to have returned)
Code: [Select]
On branch cheat_editor_ui_redesign
Your branch is up-to-date with 'origin/cheat_editor_ui_redesign'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   res/xml/preferences_global.xml

no changes added to commit (use "git add" and/or "git commit -a")

$ git checkout master    (can't check out master again)
Code: [Select]
error: Your local changes to the following files would be overwritten by checkout:
        res/xml/preferences_global.xml
Please, commit your changes or stash them before you can switch branches.
Aborting

$ git checkout -- res/xml/preferences_global.xml    (this should overwrite local changes for that file)
$ git checkout master    (but no dice)
Code: [Select]
error: Your local changes to the following files would be overwritten by checkout:
        res/xml/preferences_global.xml
Please, commit your changes or stash them before you can switch branches.
Aborting

$ git stash    (this should also discard local changes .. interesting output here)
Code: [Select]
warning: CRLF will be replaced by LF in res/xml/preferences_global.xml.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in res/xml/preferences_global.xml.
The file will have its original line endings in your working directory.
Saved working directory and index state WIP on cheat_editor_ui_redesign: 144134a front: Made preference activities navigational using a controller.
HEAD is now at 144134a front: Made preference activities navigational using a controller.

$ git checkout master    (didn't help, but the previous output looks relevant)
Code: [Select]
error: Your local changes to the following files would be overwritten by checkout:
        res/xml/preferences_global.xml
Please, commit your changes or stash them before you can switch branches.
Aborting

So this looks like an issue with line-endings for file res/xml/preferences_global.xml (that dern Windows versus Linux issue).  As you can see from one of the steps above, I could potentially work around the issue by using --force option on the call to checkout each branch, but I would like to resolve the problem "correctly" if possible.  Maybe there is an issue with the repository's .gitattributes file, or with my local git settings on the auto-build machine?  Do any of you all have some knowledge of Git and line-ending issues like this one?

9
General Discussion / Cleaned up threads posted in wrong boards
« on: January 03, 2015, 09:57:13 PM »
I moved a lot of threads that were posted in the wrong boards to their proper location, based on the topic.  If a thread you posted appears to be missing, check another board.  Most threads that were moved are now in Android Support, with some in OUYA Support, and a few in Announcements, General Discussion.

10
General Discussion / Problem building from command line (Linux)
« on: January 01, 2015, 04:46:12 PM »
Just realized I can no longer build from the command line.  ndk-build runs fine, but ant fails, with the following output:

Code: [Select]
Buildfile: /home/paul/workspace/mupen64plus-ae/mupen64plus-ae/build.xml

-set-mode-check:

-set-debug-files:

-check-env:
 [checkenv] Android SDK Tools Revision 24.0.2
 [checkenv] Installed at /home/paul/bin/android-sdk

-setup:
     [echo] Project Name: Mupen64Plus
  [gettype] Project Type: Application

-set-debug-mode:

-debug-obfuscation-check:

-pre-build:

-build-setup:
[getbuildtools] Using latest Build Tools: 21.1.2
     [echo] Resolving Build Target for Mupen64Plus...
[gettarget] Project Target:   Android 4.4.2
[gettarget] API level:        19
     [echo] ----------
     [echo] Creating output directories if needed...
    [mkdir] Created dir: /home/paul/workspace/mupen64plus-ae/mupen64plus-ae/bin/rsObj
    [mkdir] Created dir: /home/paul/workspace/mupen64plus-ae/mupen64plus-ae/bin/rsLibs
     [echo] ----------
     [echo] Resolving Dependencies for Mupen64Plus...
[dependency] Library dependencies:
[dependency] No Libraries
[dependency]
[dependency] ------------------
     [echo] ----------
     [echo] Building Libraries with 'debug'...
   [subant] No sub-builds to iterate on

-code-gen:
[mergemanifest] No changes in the AndroidManifest files.
     [echo] Handling aidl files...
     [aidl] No AIDL files to compile.
     [echo] ----------
     [echo] Handling RenderScript files...
     [echo] ----------
     [echo] Handling Resources...
     [aapt] Generating resource IDs...
     [aapt] /home/paul/workspace/mupen64plus-ae/mupen64plus-ae/bin/AndroidManifest.xml:21: error: No resource identifier found for attribute 'isGame' in package 'android'
     [aapt]

BUILD FAILED
/home/paul/bin/android-sdk/tools/ant/build.xml:653: The following error occurred while executing this line:
/home/paul/bin/android-sdk/tools/ant/build.xml:698: null returned: 1

Total time: 1 second

It appears to not understand the attribute "android:isGame" in the application tag.  Googling didn't bring up a lot of results.  Anyone else encounter this before?

One thing I do notice in the output that looks wrong, is that it indicates the target is API level 19, when it sould be 21.  The project.properties and manifest indicate 21, so not sure where the 19 came from.  Maybe figuring that out will fix the other problem..

11
General Discussion / 3.0 Alpha Testing
« on: December 06, 2014, 02:42:17 PM »
Current Alpha Release:

Alpha 21
14f135d

Upstream changes:
 - Fix regression in Conker's Bad Fur Day (crash on start)


Alpha 20
0488d08

Upstream changes:
 - All new GLideN64 video plugin by gonetz (Sergey Lipskiy)
    - Aims to be most accurate of all video plugins
    - Variants for GLES 3.1, 3.0, 2.0 devices
    - Greatest accuracy/speed with newer GLES 3.1 devices
    - High-resolution texture support
    - Still under active development; expect some bugs
    - Front-end config will be polished for usability in next alpha release
 - All new SLES-based audio plugin by Gillou68310
    - Aims to be leaner and more accurate than old audio plugin
    - New default audio plugin, old plugin still available
 - core: Fix GameShark cheat codes not sticking
 - SDL2: Fix some thread key deletion issues in SDL 2.0.0
 - Upstream Mupen64Plus version is now 2.5

Front-end changes:
 - All new gallery screen by BonzaiThePenguin
    - Grid view with cover art
    - Recently played section
    - Search bar
    - Navigation drawers
    - Long-click gallery item to instantly resume game
    - Some reorganization of settings menus
 - Material Design look and feel in almost all areas of UI
 - More consistent look and feel across all Android versions
 - Lots of internal refactoring to facilitate UI overhaul
 - Fix launching from external app (e.g. file manager app)
 - Updated translations


Previous Builds:

Spoiler: "Previous Alpha Releases" • show

Alpha 1
54dc749
 - Major refresh of front-end
 - See here for design discussion

Alpha 2
4f373fa
 - Fix crashing when rebuilding the games list

Alpha 3
d26ab43
 - Fix some games not selectable from gallery

Alpha 4
02c3da3
 - Rename some things in ROM info cache to avoid confusion

Alpha 5
3e8dc4c
 - Aggressively sync most diffs with upstream video-glide64mk2
 - Implement crash handler to save crash reports to disk
 - Update ACRA to more recent dev build
 - Add menu item in gallery for peeking at logcat

Alpha 6
10988f5
 - Show toast when saving screenshot
 - Add in-game menu item to save screenshots
 - Override new glide defaults in Alpha 5 (vsync, wrpAnisotropic, fb_read_always)

Alpha 7
fa36871
 - Toast diagnostic info if core fails to launch
 - Revert aggressive glide syncs from Alpha 5
 - Resync only benign diffs with upstream video-glide64mk2

Alpha 8
f012c42
 - Allow user to reset per-game settings to their defaults
 - Rename game-specific directories using immutable header info
 - Use a separate mupen64plus.cfg for each game (allow expert settings per-game)
 - Robustify ROM meta-info lookup
 - Add support for Android TV launcher
 - Change default vertical position from "center" to "top"

Alpha 9
225d958
 - Core dynarec fix #1
 - Core dynarec fix #2
 - Using vanilla upstream rsp-hle
 - Using vanilla upstream video-rice
 - Partially sync other upstream modules

Alpha 10
652dd31
 - Simplify glide frameskipper implementation a bit
 - A bit more aggressive syncs with glide upstream

Alpha 11
e66efb3
 - Update translations
 - Add Finnish (Suomi) language option
 - Rename emulation profiles and make Glide-Fast the default
 - Fix touchscreen not being disabled
 - Cancel ROM search if app goes to background
 - Core dynarec fix #3
 - Core dynarec fix #4
 - Sync core fixes: Zelda (subscreen delay, end credits), Pokemon Snap (pass level 1, controller fix, picture selectable)
 - Using vanilla upstream core

Alpha 12
762b18e
 - Remove most gl cache functions in glide (regressions expected)
 - Use upstream audio-resampling implementation
 - Using vanilla upstream audio-sdl

Alpha 13
3beac96
 - Add Fuhu Nabi 2 to hardware profiler
 - Remove all gl cache functions in glide (regressions expected)

Alpha 14
6c2cc67
 - Revert gl caching changes made to glide in Alphas 12 and 13

Alpha 15
c7fb2b3
Front-end changes:
 - Fix bug in MD5 calculation -> better ROM lookups
 - Use better ROM meta-info defaults if ROM not found

Alpha 16
cbf2e50
Front-end changes:
 - Add .nomedia files to exclude cover art, skins from Android photo gallery
 - Enable polygon offset hack to be disabled
 - Flatten global settings menu
 - Update game wiki URL to new site
 - Better detection/rejection of ROM files when searching
 - Fix bug in cheatfile merging on (re)install
 - Implement ROM extraction from zip archives
 - Separate directories holding cover art and unzipped ROMs
 - Rename directory GalleryData -> GalleryCache
 - Show ROM search/extraction progress in much greater detail
 - Provide easy cancellation of ROM search/extraction
 - Provide options to search zips, download art, and clear gallery when scanning ROMS
Upstream changes:
 - video-glide64mk2: ceabea7 correct N64 ROM header analysis for the regional PAL indication
 - core: Major refactoring (code cleanup) by bsmiles32 (no performance change expected)
 - Using vanilla upstream ui-console
 - Using vanilla upstream video-glide64mk2
Other notes:
 - Using vanilla upstream for all modules

Alpha 17
9c0c381
Front-end changes:
 - Fix crash caused by corrupt zip files
 - Fix mapping issues with Amazon Fire controller
 - Add more logging during core startup and shutdown
 - Remove ACRA bug reporting system
 - Simplify global settings a bit
Upstream changes:
 - video-rice: Fix most regressions since 2.4.4
 - core: Fix audio latency

Alpha 18
02025b3
Front-end changes:
 - Update translations
 - Add Arabic (Saudi Arabia) language option
Upstream changes:
 - core: Major refactoring and cleanup, no performance change expected

Alpha 19
99ce095
Upstream changes:
 - core: Major refactoring and cleanup, no performance change expected
 - new_dynarec: Implement recompiled DMULT/DMULTU instruction on ARM
Front-end changes:
 - Fix auto-hold for touchscreen controls*
 - Fix Xperia Play touchpad skin (c-pad)
 - Fix editing/adding cheats with options
 - Simplify some under-the-hood JNI/thread stuff
 - Fix loading the auto-hold button images*
 - Add drag and drop touchscreen layout editing*
* Thanks to new contributor BonzaiThePenguin :)

Alpha 20
0488d08
Upstream changes:
 - All new GLideN64 video plugin by gonetz (Sergey Lipskiy)
    - Aims to be most accurate of all video plugins
    - Variants for GLES 3.1, 3.0, 2.0 devices
    - Greatest accuracy/speed with newer GLES 3.1 devices
    - High-resolution texture support
    - Still under active development; expect some bugs
    - Front-end config will be polished for usability in next alpha release
 - All new SLES-based audio plugin by Gillou68310
    - Aims to be leaner and more accurate than old audio plugin
    - New default audio plugin, old plugin still available
 - core: Fix GameShark cheat codes not sticking
 - SDL2: Fix some thread key deletion issues in SDL 2.0.0
 - Upstream Mupen64Plus version is now 2.5
Front-end changes:
 - All new gallery screen by BonzaiThePenguin
    - Grid view with cover art
    - Recently played section
    - Search bar
    - Navigation drawers
    - Long-click gallery item to instantly resume game
    - Some reorganization of settings menus
 - Material Design look and feel in almost all areas of UI
 - More consistent look and feel across all Android versions
 - Lots of internal refactoring to facilitate UI overhaul
 - Fix launching from external app (e.g. file manager app)
 - Updated translations

Spoiler: "Diagnostic Test Builds" • show


Alpha 5b (Glide64 no rotation comparison) 4fe367f




Testing Guidelines:

Bugs in Rice video should only be compared to version 2.4.4 on the Play store.  Do not bother using or comparing Rice in Alphas 1-16.

Important note to all testers: [Starting from] Alpha 5 [the app] saves diagnostic crash logs to your SD card, which should help us track bugs down a lot faster.  They are timestamped and placed in <sdcard>/mupen64plusae-v3-alpha/CrashReports/.  If you observe a crash, please post the contents of a crash log here.

Rest assured that we will add an option to disable/clear crash logs in a future release.  For now testers will have to clear them manually (each one is a only few kB).

For those who are new to software development, a regression is a bug that did not exist in a previous build, but now exists in a new build.  In other words, a regression is a new bug.

It would help tremendously if testers could provide very specific information:
 1. What new bug are you seeing
 2. What is the first alpha version that displays the bug
 3. What is the last version that does not display the bug
 4. The exact ROM name as shown at the top of the play menu or in the gallery
 5. A savestate so that we can easily reproduce the problem
 6. Ideally, two screenshots of the same scene: one with the bug and one without the bug

Please try your best to answer all six items above, so that we don't have to keep asking more questions.  You can take savestates -- and now screenshots -- very easily using the in-game menu.
 - Savestates are saved to mupen64plusae-v3-alpha/GameData/<ROMname>/UserSaves
 - Screenshots are saved to mupen64plusae-v3-alpha/GameData/<ROMname>/Screenshots

If you find a bug that is (to the best of your knowledge) in all Alpha versions, please describe it in similar detail, and say it's a general bug that exists in all the Alphas.


Upgrade Notes:

testers will have to manually "Reload App Resources" when going from Alpha4 (or earlier) to Alpha5, and vice versa.  This is located in
    Global Settings->Data->Reload App Resources

12
General Discussion / Testing 2.5.0
« on: December 02, 2014, 08:08:04 PM »
This is the release candidate for 2.5.0.  Anyone who would like to test, feel free and please post if you find any issues.

2.5.0 RC1

2.5.0 RC2 (Lollipop MOGA crash test)

2.5.0 RC3 (New squashed branch)


If you have any previous test builds installed, you may need to uninstall them first to avoid signature conflicts.

13
General Discussion / Preparing 2.5.0
« on: November 08, 2014, 02:36:57 PM »
Starting a thread to talk about my progress with 2.4.5 (just so everyone knows I haven't disappeared again).

First step was to pull from upstream (https://github.com/mupen64plus/mupen64plus-*) into our forked repositories (https://github.com/mupen64plus-ae/mupen64plus-*).  I have completed this step.

Gillou68310 should now be able to commit his dynarec fixes to our forked repository https://github.com/mupen64plus-ae/mupen64plus-core, so from there I will be able to submit a pull request to Richard, and also merge it down into our main repository.

My next step is to merge the changes from upstream down into our main repository.  I have started this, but it has turned out to be somewhat more complicated than I was anticipating.  Various things were moved and renamed on master to make syncing with upstream simpler.  Unfortunately this doesn't help syncing to the 2.4-bugfixes branch.

My initial attempt was to sync core, rsp-hle, ui-console (front-end), audio-sdl, gles2rice (video-rice), and gles2glide64 (video-glide64mk2) all in one fell swoop.  After some conflict resolution, however, I reached an impasse with gles2glide64.  Getting errors like:

Code: [Select]
jni/gles2glide64/projects/android/../../src/Glitch64/glState.cpp:84:13: error: previous declaration of 'void cache_glClearColor(GLclampf, GLclampf, GLclampf, GLclampf)' with 'C++' linkage
/home/paul/bin/android-ndk-r10c/platforms/android-9/arch-arm/usr/include/GLES/gl.h:594:25: error: conflicts with new declaration with 'C' linkage
jni/gles2glide64/projects/android/../../src/Glitch64/glState.cpp:99:13: error: previous declaration of 'void cache_glClearDepthf(GLclampf)' with 'C++' linkage
/home/paul/bin/android-ndk-r10c/platforms/android-9/arch-arm/usr/include/GLES/gl.h:595:25: error: conflicts with new declaration with 'C' linkage
jni/gles2glide64/projects/android/../../src/Glitch64/glState.cpp:148:13: error: previous declaration of 'void cache_glDepthRangef(GLclampf, GLclampf)' with 'C++' linkage
....

Soo.. trying to do everything at once was a bad idea.  I will need to scrap my local changes and try again.  This time I will be a little more careful:

Step 1: Sync only core, rsp-hle, and audio-sdl
    Commit these three together, since they tend to be the easiest to sync from upstream

Step 2: Sync front-end (ui-console)
    Commit separately so I can back out if there are problems.  This library likely doesn't need to be updated anyway.

Step 3: Compile and test the app using gles2n64 to see if any new problems arose
    If front-end update created issues, back out of the previous commit and test again.

Step 4: Sync gles2rice (video-rice)

Step 5: Compile and test the app using gles2rice to make sure the update worked

Step 6: Sync gles2glide64

Step 7: Attempt to debug the aforementioned problem.  If unable, back out of the previous commit and leave updating gles2glide64 to someone smarter :P

14
Paul's Projects / N64 Cartridge Dump (for Gameshark Pro)
« on: September 13, 2014, 09:27:28 AM »
-- This slot is reserved for the most recent working releases --

15
General Discussion / I'm alive ;D
« on: August 22, 2014, 12:06:47 AM »
Hey, everyone, it has been a while since I've been on the forum (obviously).  Just wanted to let everyone know that I am still alive, and to explain why I haven't been around.  Oh, and thank you xperia64 for really helping out!

Those of you who have known me from groups other than my forum here (probably not many of you) might know that I have many, many interests and hobbies.  Some of my other hobbies include freshwater aquariums (I even have four 10-gallon tanks in my closet for experimenting with guppy genetics), I enjoy capturing reptiles, gardening, I collect rose bushes, and I love experimenting with various plant propagation techniques (I currently have three air-layered branches on the pecan tree in our back yard for example).  In the past I've had many other varried hobbies as well, including rocketry, rabbit hunting with beagles, teaching and showing dogs in obedience and agility, and raising show cavies (guinea pigs).

I tend to jump into new hobbies with both feet.  Examples that everyone here probably knows about: when I was teaching myself Java I wrote the SoundSystem library.  Soon after buying my first Android phone, I started the Mupen64Plus AE project.  Notice a pattern?  These are just two recent examples, but really every large project I've started in the past has coincided with a new interest.

Well, a friend of my wife recently got me interested in planting bananas.  True to my nature, we soon had six varieties of banana plants growing in our yard, and I am now working on a new big project: developing a new method of tissue-culturing bananas, cheaply, organically, and with recycled common household items and products.  I have plans for a new forum centred around bananas, videos and tutorials for keeping them in colder climate zones, and fun projects like the "kitchen tissue culturing" one I'm working on now.

So what's the point of all this rambling?  Well, between my new project, a tight budget, and being very busy with work, that is why I have not been involved on here for the past few months.  Part of the reason for a complete 180 with my new hobby, is that now my actual job is computer programming.  This has made it considerably less appealing to do in my free time (my previous job had nothing to do with computer programming, so that is why many of my previous projects were computer-related).

All this said, I realize that I do have an obligation to the community here, so I plan to start logging on more often, and get back to publishing updates again.  I probably won't be committing anything significant myself for the foreseeable future.  I'll try and get back up to speed over the next few days.. I honestly have no idea what has been going on with Mupen64Plus lately (that's the beauty of open source projects-- they don't depend on one person!)

Pages: [1] 2 3 ... 12