Next Experiment, Senseye

The development strategy behind Arcan has always been to work with experimental proof of concepts doing ‘traditional’ tasks in odd way and use that as feedback to refactor and improve the Engine, API, testing and documentation.

For instance — the Video decoding, encoding and tagging experiments added process separation and greatly helped shape the shared memory interface. The arcade frontend experiments à Gridle improved support for odd input combinations (2 mice, 3 keyboards and 5 gamepads? not a problem), support for synchronization with time sensitive processes (libretro frameserver) where buffering and other common solutions were not available. The AWB experiments helped define controlled and segmented data sharing, along with performance considerations in tricky UI situations (hierarchies of windows where size and position relied on dynamic sources, drag+resize and watch hell break lose).

The end goals, getting a portable graphics- focused backend for putting together embedded, mobile and desktop system interfaces; balancing security, performance, stability and no-nonsense style- ease of use — is still out of reach, but great strides have been made. The last couple of months have mostly been stuck documenting, testing and working with the corners that dynamic multiscreen entails.

The next experiment in this regard is Senseye, which is targeted towards the more rugged of computing travellers; the reverse engineers, the security ‘enthusiasts’ and the system analysts. It is a tool for navigating and controlling non-native representations of large, unknown, binary data streams and blocks. Both statically in terms of files and dumps, and dynamic through live acquisition of memory from running processes.

The video above shows using senseye for navigating a suspicious binary and for poking around the memory pages allocated by pid 1 (still init though in its twilight..).

Posted in Uncategorized | Leave a comment

Removing the Scaffolding

Those of you that are monitoring the Github page have likely noticed that a lot of things has changed during the last few days. The lack of activity on this page in recent months do not correlate to a lack of activity in the project overall, on the contrary.

The upcoming version, 0.5, was planned to be the last version that had anything directly to do with emulators but that plan was scrapped in favour of moving the project to its next intended phase slightly ahead of schedule. The previous emulation / HTPC frontend work was always intended to be an intermediate target for aggressive prototyping when figuring out what features were actually needed in the Lua API — not as a goal in- and by- itself.

At the moment, the contents of the git are unsuitable for emulation and frontend purposes — stick with the latest tagged release for that. The tools and scripts used for emulation are being updated and moved to a separate Git, and the plan is still to make sure those of you that are using gridle/awb/other projects can continue to do so while still taking advantage of advances in the engine.

What is this ‘next phase’ then? Well, some of the details will be left hanging for a while longer, but one of the major end-goals for this project is to find a different approach to how desktop environments should work by taking advantage of some of the good parts from the game development world (API design, performance, minimizing latency), emulation (state management, odd and weird input devices), the X Windows System (data sharing, allowing window managers to provide a choice in interaction schemes) and other areas.

To see this plan in another perspective:

Part of this goal is also to reduce the barrier-to-entry for developing real-time graphics applications, even desktop environments, and especially ones targeting the recent onslaught of low to medium powered ‘all in one board’ devices like the Raspberry Pi.

The other side of this is to act as a counterweight to current development trends towards ‘fixing the desktop’. One such trend is the one of embedding the most overly complex pile of legacy and liability that humanity has produced so far (also known as “the web browser”) everywhere — ultimately ending up in a place where nothing works if you’re behind a malicious DNS server, forcing you to constantly relearn how to interact with it because the interface had yet another lousy morning and decided to rearrang itself by moving the features you used the most to the place where you are the least likely to find them. 

Another one, which is possibly even more damaging, is trying to ‘fix things’ by introducing hordes of PolicyServiceKitManagerSystemInstanceFactoryBusObserver dependent applications that try to automate action on behalf of the user in response to some “complex” dynamic system event like the user plugging in <some device> into a USB port (thinking that means the user wants to mount the filesystem on the device, synch all the contents to a cloud storage service while being given helpful shopping advice based on the pictures stored), a world where every little component is unknowingly responsible for something that is unrelated to its own function and thus unable to take responsibility for malfunction — thus no-one will be pushed to act on the fact that your music player in the background grinds to a halt because the SoundServiceSystemManagerListener live-locked when your network connection dropped because you moved to a different WiFi access point.

The ambition here is, in stark contrast to the two scenarios mentioned above, to provide the user with the tools necessary to easily and clearly convey his or her own actual intent behind the action that the system observed < some device was plugged in >, along with the tools to only grant applications temporary and limited access to selected parts of the user’s data– and to upgrade the UNIX pipes and filters model of ‘do one thing but do it well‘, rather than to try and replace it with a selected mix of all the bad parts associated with Windows and Android.

But that is a longer story — to be continued.

Posted in Uncategorized | Leave a comment

Not Dead

Far from it! Unfortunately, a whole lot of the changes ahead are a step up in technical difficulty and low on visual goodies. The tentative plan at the moment is a 0.5 push in August, which depends a bit on how long it will take to port all the internal changes to the windows platform and on how hard I fail cryptography engineering in the networking protocols.

As an example of the current state of new features, the screenshot below (from the AWB scripts) illustrates:

  1. An external, non-authoritative connection of lightweight-arcan (LWA) running ‘Gridle’ where the engine is used as both display server/window manager and has another version of itself connected. LWA mode still lacks sound as I have to write an OpenAL-soft backend driver that uses the shared memory API. (coordinate system messed up in the screenshot).
  2. A remoting frameserver connected to a VirtalBox Headless VM running PC-BSD over VNC.
  3. A VNC server that (using a version of the recording tool) maps the LWA connection from 1 and the client from 2, with input translation and all.
Preview of some of the upcoming features in 0.5

Preview of some of the upcoming features in 0.5

Posted in Uncategorized | Leave a comment

Looking Ahead

While there are quite a few enhancements planned as evident from the issues tracker on github, the subset that is currently being focused on in the near future and what it will be used for is not quite as clear, so while a new release are many weeks away, here is the current focus and a status update of sorts:

“Big changes”:

  • Extending the shared memory interface to accept multiple input/output segments for one frameserver. This will, in the libretro and hijack cases, be used for in situ texture manipulation, and for the longer perspective, allow the support for multiple windows (some MAME cases..) and for streaming network A/V transfers (minor details and a lot of testing left).
  • Extending the shared memory interface to accept (foreign, external, “non-authoritative”) connections. This is partially related to the previous point, but under certain conditions, allow external processes to connect and act as any other frameserver even though the trust domain has not been explicitly defined in beforehand (as is done with the database for target_launch today). (minor details and a lot of testing left).
  • Extending the platform support to EGL/KMS/ARM/… Parts of this was present, but not really emphasized, in the 0.4 release in that we have support for EGL and, in particular, the Raspberry Pi brand. This is was an experimental step to determine how much work would be needed to get things working on more competent ARM platforms. The big thing missing here still is BSD/Linux raw /dev/input- style support for various devices along with select optimizations for some of math intensive parts (particularly a few ARM NEON/softfpu implementations of 4x4matr- mul and 4x4matr- vec3 transforms).
  • Getting recursive. Arcan will be capable of using itself as a “hardware” platform, meaning that the shared memory interface will be used for A/V/Input, and that the engine can launch itself (and with different sets of scripts) so that it fills the roll of desktop environment, compositor and “app-engine” all in one. This is experimentally working for video (with some manual labour) but some ways to go still with audio (~a days work to hack together an openAL-soft backend) and input (~another day to translate events properly).
  • Engine optimization; tracking changes on a “per rendertarget” basis and only update when something really has changed, and only update dirty areas for the 2D pipeline (quadtree with batching), and “blit-vid-to-vid” using FBOs as an intermediary for dynamic sprite sheets. Clipping, finally, will get a cheaper version for CLIP_SHALLOW on non-rotated objects to work without needing the stencil buffer.

At the same time, some parallel projects are being worked on (like a BSD/Linux terminal emulator, no points for guessing why), with the bigger one being to integrate and tune all the existing networking code for state synchronisation (aka netplay).

Posted in Uncategorized | Leave a comment

0.4.0 Released

This was long overdue, but I finally got satified enough to tag a new release. A lot of engine- “under the covers” work in this one in regards to the LuaAPI, documentation, build systems, portability and performance to prepare for things to come. Among the features that some end-users might appreciate, we have:

  • enhanced configuration, filtering and tuning for analog input devices
  • support for 3D libretro cores
  • support for libretro core options
  • mouse-analog device translation
  • (AWB) per game/per target coreoptions/input configuration
  • (Gridle) custom layout can now include the game display as part of the layout

No video this time around, but the individual wikis ( AWB Gridle ) have annotated screenshots to better explain the features.

The boring and full release notes can be found here: [Full Release Notes]

Arcan Workbench Screenshot (0.4.0)

Arcan Workbench Screenshot (0.4.0)

Customview Layout Editor (0.4.0)

Customview Layout Editor (0.4.0)

N64 Libretro core in Gridle internal launch

N64 Libretro core in Gridle internal launch

Infrastructure wise, we are now rid spam-forge. Main repository will be kept @ github and binary releases @ bintray.

This is the last version where Gridle / AWB will be released synchronously and bundled. They now have their own github repositories so you can get your updates more frequently than the release cycle of the engine. In the coming version, we’ll focus more on social features (netplay, …) ARM devices (and living life without X) and a package format.

Download links are in the menu above.

Enjoy /B

Posted in Uncategorized | Leave a comment

0.4.0 Quick Update

The next release is just around the corner, assuming no big show-stoppers appear during testing. Without making any promises, it seems likely that 0.4.0 will be packaged and pushed 30/1 or 6/2.

Update: there wasn’t much in terms of show-stoppers (well, for win32 there are) but other valid external requests that pushed for some changes that would be good to package into the release, thus the next version is delayed a few weeks more. Those brave enough building from source have most things available already.

The bigger changes is notably better analog support and fine-grained configuration for analog devices, support for libretro coreopts and 3D based cores (n64, …) but a whole lot (some 100+) fixes and optimizations that make for a rather boring changelog.

Until the time of release, the long-coming infrastructure switch to a combination of github (wiki, source and issue management) and bintree (for distributions / core downloads) is moving to an end and I’ve started fleshing out the wiki again (e.g. guides like and )

With any luck, will lead to some kind of actual change in the terrible ffmpeg- packaging situation for debian/ubuntu so we can start providing binary releases for those kinds of distributions again.

Posted in Uncategorized | Leave a comment

0.4.0 WIP

0.3.2 WIP

Closing in on libretro-3d core support

Image | Posted on by | Leave a comment