Show Posts

1

Mini Projects / Dad's Song HTM

« on: June 23, 2018, 08:10:57 PM »

Inspired by an interview that Matt recently had with with David Schneider, we have decided to form a group to model in HTM the capabilities required to achieve the zebra finch’s ability to “mimic Dad’s song”. Once we have accomplished this, we will have covered a lot of the main areas that are needed for embodying HTM, and I will be much closer to my goal of a seed AI for ARTUR.

Anyone interested in joining or just listening in on the verbose interactive brainstormy stuff is welcome to join our Slack channel

2

General Discussion / N64 gaming over the internet

« on: August 29, 2017, 08:31:21 AM »

I have been toying around with an idea for a while. While in practice it may not be feasible (from a speed perspective), it is an interesting question.

The basic idea would be a "core" library which merely does networking. It would hook up to normal audio, video, and rsp plugins, but would not actually be emulating the core or have a copy of the game ROM. This library would run on a "client" device.

Then there would be an extension of a normal core library that would run on a "server" device and transmit state information to the client.

The question is whether or not it would be legal to use a system like this for users (on the "server" device) who legally own a ROM to plan games over the network with another user (on the "client" device) who does not own the game.

Obviously nobody here is a lawyer, just thought it would be an interesting topic to discuss. Probably not even feasible (perhaps more realistic on an emulator for a lower-spec device like the NES).

3

Paul's Projects / 32bit Docker on Tiny Core Linux

« on: May 21, 2017, 08:51:32 PM »

One of the system requirements listed for running Docker is a 64bit host. I decided to conduct an experiment this weekend to see if I could build a 32bit version of Docker and have it run on 32bit Tiny Core Linux. If it works, this could in theory be combined with an x86 emulator like QEMU to run docker containers from your Android phone..

The first step was to build a 32bit version of Docker Daemon and Docker Client. I found a nice recipe for doing this HERE. I had to tweak it a bit (require checking out tag 17.04.0-ce, and using this revision of the Dockerfile).

Then I installed Tiny Core Linux 8.0 x86 in Virtual Box, and after a lot of tinkering, came up with the following recipe to get the Docker Daemon to run without crashing:

Code: [Select]

tce-load -wi bash git procps xz ca-certificates iptables net-bridging-4.8.17-tinycore

sudo ln -s /usr/local/etc/ssl /etc/ssl

sudo addgroup docker
sudo addgroup tc docker

sudo mkdir /mnt/sda1/docker
sudo mkdir /mnt/sda1/docker/run
sudo mkdir /mnt/sda1/docker/lib
sudo chown -R root:docker /mnt/sda1/docker
sudo chmod -R 770 /mnt/sda1/docker
sudo ln -s /mnt/sda1/docker/run /var/run/docker
sudo ln -s /mnt/sda1/docker/lib /var/lib/docker

echo "etc/passwd" >> /opt/.filetool.lst
echo "etc/group" >> /opt/.filetool.lst
echo "etc/shadow" >> /opt/.filetool.lst
echo "etc/gshadow" >> /opt/.filetool.lst
echo "etc/profile.d" >> /opt/.filetool.lst
echo "etc/ssl" >> /opt/.filetool.lst
echo "etc/os-release" >> /opt/.filetool.lst
echo "var/lib/docker" >> /opt/.filetool.lst
echo "var/run/docker" >> /opt/.filetool.lst

echo "#!/bin/bash" >> /etc/profile.d/paths.sh
echo "export PATH=\$PATH:/home/tc/dockerd:/home/tc/docker" >> /etc/profile.d/paths.sh
chmod 755 /etc/profile.d/paths.sh

sudo touch /etc/os-release
sudo chown root:staff /etc/os-release
sudo chmod 664 /etc/os-release
echo "NAME=\"Tiny Core Linux\"" >> /etc/os-release
echo "ID=tinycore" >> /etc/os-release
echo "VERSION_ID=\"8.0\"" >> /etc/os-release
echo "PRETTY_NAME=\"Tiny Core Linux v8.0 x86\"" >> /etc/os-release
echo "HOME_URL=\"http://tinycorelinux.net/\"" >> /etc/os-release
echo "BUG_REPORT_URL=\"http://forum.tinycorelinux.net\"" >> /etc/os-release

cd ~
mkdir dockerd
mkdir docker

cd ~/dockerd
wget http://www.paulscode.com/downloads/dockerd.zip
unzip dockerd.zip

wget https://raw.githubusercontent.com/tianon/cgroupfs-mount/master/cgroupfs-mount
chmod 755 cgroupfs-mount

cd ~/docker
wget http://www.paulscode.com/downloads/docker.zip
unzip docker.zip

Then after a reboot:

Code: [Select]

sudo su
export DOCKER_RAMDISK=true
ulimit -Hn 65535
ulimit -Sn 65535
cgroupfs-mount
dockerd

However, when I ran a test of Docker Client, it failed with an error message about insufficient disk space. This was related to a message from the Docker Daemon complaining that the kernel didn't support the "overlay" filesystem. I ended up having to rebuild the Tiny Core kernel, setting flags "CONFIG_OVERLAY_FS" and "CONFIG_CFS_BANDWIDTH"

Code: [Select]

wget http://tinycorelinux.net/8.x/x86/release/src/kernel/linux-4.8.17-patched.txz
wget http://tinycorelinux.net/8.x/x86/release/src/kernel/config-4.8.17-tinycore
tar -xvf linux-4.8.17-patched.txz
cp config-4.8.17-tinycore linux-4.8.17/.config
cd linux-4.8.17

gedit .config
    CONFIG_OVERLAY_FS=y
    CONFIG_CFS_BANDWIDTH=y

make bzImage

Then I put the generated bzImage into the boot directory at /mnt/sda1/tce/boot, and and updated the bootloader:

Code: [Select]

DEFAULT bzim
LABEL core
KERNEL /tce/boot/vmlinuz
INITRD /tce/boot/core.gz
APPEND quiet  waitusb=5:UUID="fee3c2ac-3bf2-4aa1-ae8e-73fa95f4ea2c" tce=UUID="fee3c2ac-3bf2-4aa1-ae8e-73fa95f4ea2c"
LABEL bzim
KERNEL /tce/boot/bzImage
INITRD /tce/boot/core.gz
APPEND quiet  waitusb=5:UUID="fee3c2ac-3bf2-4aa1-ae8e-73fa95f4ea2c" tce=UUID="fee3c2ac-3bf2-4aa1-ae8e-73fa95f4ea2c"

Finally, after a reboot, I am able to successfully run Docker containers in 32bit

4

Mini Projects / HTM.js

« on: April 17, 2017, 01:26:29 PM »

I have decided to start cleaning up my javascript implementation of HTM and publish it on GitHub in case anyone finds it useful. This is a lightweight implementation of HTM which can be run client side in the browser (useful for quick demos to explore and discuss various HTM-related concepts and theories).

I have committed the refactored code for spatial pooling and temporal memory, and added "HTM Piano" as an example of how to use it. It is now up on GitHub

I'll be adding the code for sensory motor integration and reinforcement learning next, and I'll be including the source code for all of my future demos that use HTM.js as well.

Latest revision of master will also be deployed on the paulscode.com server. This will provide easy access to the latest demos.

5

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

6

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.

7

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.

8

Theory and Discussion / What is ARTUR?

« on: October 24, 2016, 04:10:03 PM »

- This slot is reserved for the project roadmap and links -

9

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.

10

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.

11

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.

12

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?

13

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.

14

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

15

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

Spoiler: "Diagnostic Test Builds" • show

Testing Guidelines:

Quote from: littleguy on January 29, 2015, 07:53:33 AM

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.

Quote from: littleguy on December 09, 2014, 06:50:50 AM

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

Quote from: littleguy on January 03, 2015, 07:50:47 PM

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:

Quote from: littleguy on December 10, 2014, 07:41:05 PM

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

Topics - Paul

Mini Projects / Dad's Song HTM

General Discussion / N64 gaming over the internet

Paul's Projects / 32bit Docker on Tiny Core Linux

Mini Projects / HTM.js

Theory and Discussion / HTM Reinforcement Learning

Mini Projects / HTM Robot Lab

Mini Projects / HTM Piano

Theory and Discussion / What is ARTUR?

Announcements / Forum Rebuilt

General Discussion / Bad luck..

General Discussion / Bandwidth Limit Exceeded

General Discussion / Auto Build Issues

General Discussion / Cleaned up threads posted in wrong boards

General Discussion / Problem building from command line (Linux)

General Discussion / 3.0 Alpha Testing