Unity and the Raspberry PI?

Yes, and it represents the best chance of getting Unity games onto the Raspberry Pi 3.

 

I have been able to play Unity Games on the Pi3 now. If you want to try here is a how to http://www.instructables.com/id/Raspberry-Pi-Running-Unity

 

To be clear, is this for running Unity games on the Pi or for running the Unity Editor on the Pi?

 

Running Unity games *note I haven't really tested anything with great graphic.

 

What about the CHIP a $9 computer -> http://www.gizmag.com/chip-nine-dollar-tiny-computer/37469/

It has a 4 gig flash chip 'HD', 512 mb memory and an ARM soc similar to the Pi, but only $9.

Note: It uses the Allwinner ARM cpu, which apparently has a Mali 400 GPU, as seen in Allwinner A13 tablets and devices.

A13 cpu -> http://www.allwinnertech.com/en/clq/processora/A13.html

 

It may have stronger graphics but it only has one core, half the memory, and a very restrictive amount of storage. I have had Android tablets with similar specifications and they weren't useful beyond simple ebooks and even then they struggled.

Besides the Raspberry Pi Zero is cheaper at $5.

Technically it's the Allwinner R8 SoC which is simply an A13 with the LCD and touchscreen controller embedded in it.

 

Until you need to buy a flash card.

 

Barring purchases from an expensive convenience store, or a large capacity card, you can easily find one for cheap.

https://www.amazon.com/Kingston-microSDHC-Memory-SDC4-8GBET/dp/B00200K1TS (Kingston 8GB - $4)

If you don't want to pay shipping you can find them at super markets, like Walmart, which offer free in-store pickup.

http://www.walmart.com/ip/Kingston-8GB-microSDHC-Memory-Card-with-SD-Adapter/10981796 (Kingston 8GB - $4)

Or better yet, if you check out the prices on those sites, the 16GB card is only a dollar or two more.

 

It'd be great to have a Unity demo running on CHIP once we've pushed the Mali driver out to the public.
If I remember correctly, I've gotten static Mono applications built and running on CHIP, so I don't believe it's as much a toolchain issue. The Unity runtime libraries would also need to be ported over to Linux ARMHF, though I'd imaging most of that work is done with the Android port of Unity. Unity also supports OpenGL ES, as is used on iOS, Android, and a few other ports.

That said, supporting Unity deployment for various linux distributions built on different C runtimes and libraries will get tricky. When I've got time again I'll definitely be poking around at Unity's output assemblies but there's likely only so far I can get with that. This'll really take a bit of interest from the Unity team.

 

I know this a bit of a necro-post, but it might be time to start re-examining the potential of this topic.

Later this month, the Rock 64 micro-computer is going to be coming out. It's a fairly direct competitor to the Rasperry Pi line, with similar specs, more options for different sizes of RAM, and a lower price-tag. And while the Raspberry Pi started off with a fairly limited number of OS options, the Rock 64 is going to be coming out of the gate with several, including Debian and Android support. It is likely that Unity Android APKs will be able to be side-loaded onto this thing right from the word go.

At the same time, the Raspberry Pi scene is also heating up. One of the recent ports of Android TV to the Raspberry Pi includes fairly up-to-date GPU support, finally giving apps on it a shot in the arm for rendering power. Anyone with a Raspberry Pi 3 may be able to run Unity software on it at a respectable frame-rate, or begin targeting that hardware for more limited projects. The Pi 3's built-in networking and Bluetooth options make it a desirable platform for a lot of different projects.

I just ordered a Raspberry Pi 3 myself. When it arrives I'm going to try installing Android TV and seeing if I can get a Unity deployment working.

 

Pi came in. Sadly, my weekend was busy, so I didn't get as much time as I would have liked to play with it. But I did manage to install the current release of Android TV on it, and fired it up to test basic functionality. Tonight I'm going to try side-loading applications to it.

 

I played with putting Android TV on a Pi last year and the lack of GPU support was a big problem. A deal breaker, really. Glad to hear that they are making progress.

I noticed recently that there are several independent projects working on an Android port for the Pi. Let us know which one works the best for you.

 

Boom! Nailed it. I had to jump through a few hoops to get the side-loading working. In particular, I had to install a side-loading-centric app on a secondary android device and pass the APK over that way. But in the end, it worked, and I was able to get a Unity-exported APK running natively on the Raspberry Pi 3 using Android TV.

Now I've got to cook up a test-bed Unity project and start doing some performance testing. I'm thinking I will initially focus on the various resolution rendering support with a nice FPS counter. (and maybe a few animated elements)

 

I was able to get a little more testing in today. Created a basic app for testing, and exported it to the Raspberry Pi 3. I put the basic FPS counter and resolution inspector in there with a standard GUI 2D Canvas. Just testing a standard 2D layout for now, and thankfully knocking down 60 fps at a resolution of 1280 x 720.

One annoying thing is that the build of Android TV that I'm using doesn't seem to have proper resolution settings, so I haven't been able to change the native resolution that the OS is running at. The monitor I'm using is a very nice Dell full-1080p. There's no reason why I shouldn't be able to switch the rendering mode over to 1080p. I always try to adhere to native resolutions, so this is driving me slightly batty.

Aside from that things are going smoothly. Next I'm going to see if I can't get a little bluetooth joystick action working.

 

I dug into the configuration files last night and was able to get better control of the output resolution. I was able to properly enable full 1080p. It lowered the general performance, the framerate dropped down to around 30 fps. Still within acceptable ranges, but action games would probably want to target lower resolution displays.

 

I've been doing a little more testing. Sadly, it isn't easy to get auto-scaling in the Raspberry Pi and Android configurations. This isn't too much of an issue, as there are plenty of different resolution options to insure you are able to get the settings for the native resolution of the screen you are targeting. But I kind of wanted to fine-tune the output for integer scaling, and that can't happen by default.

This isn't a limitation of the Raspberry Pi, or Android, or even Unity. No, it's an issue with the display screens themselves. Modern fixed-resolution displays simply don't play nice with resolutions they weren't designed for. Trying to feed a resolution like that into the screen won't fly.

From what I've seen so far, I'm thinking that the best approach is for me to target 720p for the actual output to the screen. (a standard resolution that my computer monitor and television are both able to accept) While this isn't exactly optimal in terms of rendering quality, it gives me the performance wiggle-room I feel I would need to maintain the kind of framerates that I'm looking for.

Now I'm going to play around with render-to-texture in order to get scaled pixel graphics, and see if I can get that looking decent with the 720p display.

 

Whooof, I did quite a bit of testing over the past few days. I settled on an 800 x 600 resolution in order to boost performance. I was also able to map a standard Logitech F310 controller to run on Android TV, with all of its face inputs returning values properly in my Unity test-bed. I was able to get both analog sticks working correctly, as well as the D-pad and all the face buttons. Oddly, the only thing I haven't been able to get running is the analog triggers. They work fine on desktop, but I haven't been able to detect them correctly on Android TV. The controller is set to X-Input mode, so it is roughly equivalent to an Xbox 360 controller. I haven't tried direct input mode, I might want to look into that eventually. For now though I'm pretty happy having most of the controller features I need reporting in correctly.

As if that weren't enough, I also got around to testing out the RenderTexture. It was kind of necessary given that I was feeding a 4:3 aspect ratio signal into a 16:9 monitor. Sadly, this is necessary. I found out in my testing that even a capable modern monitor is only designed to accept a few certain standard signals, and can't properly display any non-standard resolutions. And one of the big drawbacks of this is that most older, lower standard resolutions are 4:3 aspect ratio, or much closer to 4:3. 16:9 didn't become common until higher-resolution flat-panel displays started to take off. It's times like this that make me miss my old CRTs. Those behemoths could accept just about anything like a champ. As long as you weren't going to high, they'd display it.

But this is where the RenderTexture comes to the rescue. The aspect ratio switch stretches the final image on the screen horizontally, resulting in wider individual pixels. (obviously not actually widening the pixels, that's not possible on fixed-resolution displays, but the final rendering appears stretched) I scaled up an individual 16x16 sprite to confirm this effect. The way around this is to take a wider rendered image, and then conform it to the bounds of the camera. This will result in a squished image with more vertically stretched pixels, and when they get displayed on the monitor they will appear square. A little quick math from a base vertical resolution of 600 gives us a target horizontal resolution of 1066 (roughly) to create a 16:9 aspect ratio. I created a new camera in the scene, and connected it to a RenderTexture with a resolution of 1066 x 600. Then I created a basic quad, dropped it in front of the main camera, and applied an unlit material to it with the RenderTexture applied. A quick script I cooked up for the quad took the orthographic size property from the main camera, and dynamically scaled the quad to stretch to the bounds of the camera automatically.

And it worked like a charm. The RenderTexture worked just fine on the Android TV deployment. At an 800 x 600 resolution, I was able to maintain a steady 60 FPS, even with the RenderTexture running in the background, and the GUI elements I had created tracking the state of the controller. I had to tweak the rendering path from "forward" to "deferred." The colors were screwed up a bit while it was set to forward, but I'm pretty sure this is how it ought to be for the Raspberry Pi 3 and the version of Android TV that it's running. If I need to change things up to either increase the detail or reduce detail to boost performance, I have options. I can raise or lower the base output resolution, and I can also raise or lower the "rendered" resolution within Unity itself.

 

Any "screenshot"?

 

No, I'm not really versed in deriving screenshots from the Android environment. But I think some straight pictures would tell the story better anyway. Thankfully, I've been working on my website recently, so image uploading is no big deal now.



Here's the Raspberry Pi 3 on my desk, plugged into my Dell monitor. You can see the standard Android TV loading screen being displayed. The Logitech F310 is plugged in as the primary input device. The Android TV OS is designed to be friendly toward controller-type interfaces. It actually works better than using a keyboard or a mouse.



The standard Android TV desktop. Microphone logo in the upper left corner. The list of installed applications below it. I side-loaded the AptoideTV app in order to make it easier to install standard apps. The ES File Explorer helps in the side-loading process. And below those is the Testbed Unity app I've been tooling around with.



Dropped down in the menu to highlight the Unity app. Thanks to the various setting I tweaked in the Android export options in Unity, it is showing up in the Games section. I haven't customized the icon yet, so it's using the standard Unity icon.



And now the Unity-constructed app actually running. It's very basic at the moment, but then it's mainly just intended for putting Unity through its paces on the Raspberry Pi 3 platform, and confirming functionality of basic, essential systems. Years ago I constructed a very basic sprite sheet with all the original Zelda sprites, and frequently use it for testing purposes. That's why Link is showing up. He is a basic 16x16 pixel sprite scaled up to confirm whether or not the ratios are holding up. There's a green quad behind him, with a basic unlit color material. Both of those elements are being drawn to RenderTexture, and then that RenderTexture is being applied to a single Quad that is being scaled to exactly fit the rendered dimensions. (in this case 800x600)

The menu elements overlaid on the scene are giving feedback on some of the pertinent stats. The Raspberry Pi is outputting an 800x600 pixel signal to the monitor. The current FPS is 58. There is a single joystick connected to the system. And at present none of the buttons or joysticks are being used. All fairly standard stuff.



In this final shot you can see my hand in the bottom left. I'm operating the controller, and pressing the A button while pushing the left joystick. The values are showing up on the screen as expected.

 

This is really great work! I just purchased a pi3 and was curious if it was worth trying to use it to demo a simple 2d game.

 

Richard will you be documenting how to get Andriod installed and Unity Apps loaded on the resulting OS?

 

I will be making a tutorial for this at some point. I'm revising my website, and tutorials are going to be one of the big content pushes I make once I have my graphical template finished. To be honest though, it wasn't very difficult. Anyone who has experience using the Raspberry Pi is just a brief Google search away from getting it running. The installation process for the OS is very standard for Raspberry Pi OS installations. Getting your deployed project running on your Raspberry Pi is a bit more difficult, as you can't connect the Raspberry Pi to your computer using USB, as you likely would with most other Android devices. But even that part of the process isn't that difficult.

What was really challenging was tweaking the settings for the Pi to conform to what I needed. There was much less documentation for this use-case. Any tutorial I produce will likely focus on that aspect of the process.