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:
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).
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.
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.
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.
Win32 builds (as well as source tags etc. for Linux/BSD users) are up at the Github release page (yes, we’ve given up on sourceforge). Updated core package will be uploaded in a few days, you can also grab/extract cores from the 32-bit retroarch megapack at the libretro site.
Some more progression: Recorder tool fully mapped, core synchronization / timing, NTSC, CRT, Upscalers etc. in place. Tab- switching between windows is working and shortcuts can be added that retain filter/input/savestate settings.
An updated video on how the desktop- theme is progressing;
This one showcases the minimize changes, input configuration, media playback, background window, fixes to the recording tool etc. Most of what’s left before a first real release is mapping features existing in Gridle (all the filters etc.) and testing a few of the harder cases.