Server Subscription is now available

October 15, 2018

Server Subscription has now been available for several days already, I've fixed some glitches, thanks to the brave first users, so it's time for a proper announcement.

Server Subscription provides, well, a cloud server with Dwarf Fortress + DF Remote running on it. The price currently is 4.99 USD or a corresponding amount in other regions. A free 3-day trial is available.

  • No need to configure and maintain your own server, just download the app and start playing. Also it will help who were not able to set up a server at home due to their home and mobile network configurations.

  • You can upload and download game saves, even if your subscription expires. So it's easy to generate world, embark and start playing on desktop, continue on the go, and again on desktop when you're back home.

  • Additional online services. The first one to come will be an online 3D map viewer. The same as I've already mentioned which is available for everyone, but subcribers will have a gallery in their online account, a button to make a snapshot of their current game, and also a button in the app for that.

    Then, in no particular order: A plugin/command/tool to synchronise local games with online account. A way to play in the browser (like my old Web Fortress and not a custom UI like in the app). And some sort of a successive multiplayer support.

  • And last but not least, subscription users get updated and bug fixes faster because it's easier to investigate any issues I notice.

Subscription is an optional service that provides a pre-configured server with DF Remote. Remote server plugin will always be free for installation on your own computer. Dwarf Fortress is a game by Bay12Games available for download free of charge. Support them!

#DF Remote #Dwarf Fortress
·
September 13, 2018

Looking at the new iPhone models which are now ALL bulky flawed unusable, I feel I need to buy several pre-iPhone X phones, and an iPhone SE while I still can. For a family that uses Apple devices only for more than 10 years it's a very sad day - seeing now for sure that Apple turns to shit, and there's no alternative.

#Apple #iPhone
·

Getting there

September 10, 2018
#DF Remote #Dwarf Fortress #Server Subscription
·

Support for closed-source/commercial VCVRack plugins in miRack

June 26, 2018

Great news! I've managed to implement loading of closed-source VCVRack plugins into miRack. This means it now makes sense to build packages for desktop operating systems. And soon you will be able to enjoy all the benefits of miRack, including lower CPU usage, more responsive UI and multithreaded processing - and still use all the same plugins you have, including commercial ones you purchased.

Of course this does not affect miRack running on ARM boards - only open-source plugins can be used in that case because they need to be compiled for ARM in first place.

#miRack #VCVRack
·

Gallery of [almost] all open-source VCVRack/miRack module panels

June 24, 2018

https://mi-rack.github.io/catalog/gallery/

#miRack
·

Hardware woes

June 13, 2018

I mentioned that I got a touchscreen for my Tinker Board to use with miRack. It is a Waveshare 7" 1024x600 LCD - a very nicely built slim display without a bulky separate driver board. It has capacitive multi-touch (maximum 2 touches though) that doesn't require any drivers.

Unfortunately, touch recognition didn't work well - X coordinate was jittering and Y coordinate was just inaccurate with different error across the screen. Thinking I was just unlucky to get a bad item, I ordered another one, directly from Waveshare and this time a slightly different model - with additional film on screen and a nice black frame around, and a different control board that has audio output jack (via HDMI) and OSD with brightness and other usual controls.

Again, the build quality is quite good, but unfortunately it doesn't work quite well again. Touch recognition is much better now, no problems with that. But I'm getting some artifacts on screen, flashing lines, and occasionally the display just shows a "no signal" message. Interestingly, these problems go away if I set any resolution higher than the native one (e.g. 1280x720), so maybe it's something related to refresh rate, timings or something, but nothing I tried helped. Also, Tinker Board with this display doesn't work when connected to my power bank which wasn't a problem with the old one (it's expected the new screen draws more current, but now I think its features are probably not worth it).

There's a chance my new screen will work well with Raspberry Pi (after all, most components are designed for/tested with it and in fact the display doesn't have any issues when connected to my MBP), but being about twice slower than Tinker Board, RPi isn't a very good choice for this particular project. Also it's a shame that the official Raspberry Pi 7" touchscreen has a rediculous 800x480 resolution - more of a toy (and an overpriced one).

I don't know, I'll probably try ordering the first model again because most likely I just got a bad one in that case. But overall it's all very disappointing. I was aware that the whole SBC ecosystem isn't exactly industrial-quality, there's a lot of lower-quality components and a lot of, well, tinkering involved. But I didn't think it'd be that bad. I've already spent a lot of time and money on this but still don't even have a touchscreen neither for myself nor to recommend to people who wants to build a miRack-based device - and a good (oh well, at least properly working) touchscreen is one of the main components.

UPDATE: Looks like munually tweaking pixel clock (via Modeline option on Xorg config) affects display artifacts I'm having. I think I've made it better now although not completely eliminated yet.

#miRack #Tinker Board
·

A touchscreen for Tinker Board / miRack

May 26, 2018

A touchscreen for my Tinker Board arrived today. It's a 7" screen with 1024x600 resolution and multitouch. Good thing about it is that it's just one slim board, and just a HDMI connector and a USB connector for touch and power (no separate driver board or power connection).

So first of all I tried miRack on it, and it works quite well. There are some things that need to be sorted out for comfortable operation, like scrolling lists by dragging (for module browser), enlarging some UI elements, and tweaking plug position when connecting wires so that you can see where it is behind a finger. And then comes multitouch, support for which seems to be a mess in Linux, an which is not supported neither in the current Rack UI code nor in GLFW framework it uses. So I don't know how long it will take.

Multitouch is required at least for scrolling and zooming the patch, however I was also thinking about having a dedicated hardware joystick.

#miRack #Tinker Board
·

Debian packages for miRack are available

May 21, 2018

I've created a Debian repo with miRack packages (the main application and open-source plugins), see here for instructions and notes. The packages are for armhf architecture for now and are being tested on Tinker Board with TinkerOS, but should work on other debian-based systems (including Raspberry Pi 3 with Raspbian).

This should make installing and updating miRack much easier, and most important, will ensure that all plugins are updated as well when Rack (the main application) changes break compatibility. I don't have much experience with creating Debian packages and repositories, so let me know if there are any issues.

Also, I started working on improved touch support after noticing a related issue created in VCVRack repo, see here for details. Currently implemented are larger hitboxes for small controls and module locking to prevent accidental module movement when missing a control.

miRack - an optimised fork of VCVRack primarily targeting Raspberry Pi, ASUS Tinker Board and similar hardware (but can be used on desktop too).

#miRack #Raspberry Pi #Tinker Board
·

Boot to Rack

May 15, 2018

While waiting for a touch screen to arrive, I'm experimenting with making a minimalistic OS image for Raspberry Pi and Tinker Board that boots straight to miRack and doesn't have anything else at all to maximise performance (and possibly with a tweaked kernel if I find that necessary). I'm aware of three ways to relatively easy make a custom OS image for these boards.

First, I tried learning and using Yocto Project, and it was all working well - Yocto allows to build really small and customised Linux images relatively easy (although requiring 30GB+ of space to build a 400MB image). However the problem is that the packages it builds (it generates DEB or RPM packages for everything during the process) are compatible with the produced OS only. So if I want to make miRack packages for regular Raspbian and TinkerOS installations and also a bootable image, I'd need to do it separately which I don't want.

Then, I briefly tried Armbian's build script which also worked and, since both it and TinkerOS are Debian-based, they both will be able to use the same miRack packages. But the script is based on debootstrap script which does the main job of producing the base OS filesystem, and unfortunately it doesn't allow customisation and just installs some predefined set of base packages.

So I ended up using DietPi scripts as a base. They take a different approach, where they just remove everything but the required packages from an official Raspbian or TinkerOS system, and by default they produce a very light image, just what I need. The scripts are a bit generic though, a bit complicated, and are supposed to be run on a live system. So I had to make them run with chroot first (thanks to QEMU you can chroot into a different platform easily), and then remove everything I don't need.

Anyway, now I have a way to build minimal OS images booting straight to miRack on Tinker Board. I'm not publishing the image yet though because there's more work to be done - mainly related to Rack and plugin updates which happen ofter as I develop (and therefore also configuring a network connection without a normal desktop environment).

miRack - an optimised fork of VCVRack primarily targeting Raspberry Pi, ASUS Tinker Board and similar hardware (but can be used on desktop too).

#miRack #Tinker Board
·

Just to give you an idea what’s wrong with VCVRack

May 1, 2018

Here is a windowRun() function which is an event handling/rendering loop. It runs at VSync rate (if it's supported/enabled or at 90 FPS otherwise). Let's assume it's 60 FPS. Each frame, cursorPosCallback() is called. That functions doesn't check whether the cursor position has actually changed or not. It does number of things but we're now interested in this line where onDragMove() is called for a gDraggedWidget if it's not NULL. gDraggedWidget is set here whenever you press left mouse button over a widget. Suppose, you pressed it over a module background (not a control), then requestModuleBoxNearest() will be called here to find a new position for the module so that it doesn't overlap other modules.

So far we see that some function is being called even when it's not really neccessary - that's bad but not the end of the world, right? Then now on to the interesting part. I'll provide full code of this function here:

bool RackWidget::requestModuleBoxNearest(ModuleWidget *m, Rect box) {
    // Create possible positions
    int x0 = roundf(box.pos.x / RACK_GRID_WIDTH);
    int y0 = roundf(box.pos.y / RACK_GRID_HEIGHT);
    std::vector positions;
    for (int y = max(0, y0 - 8); y < y0 + 8; y++) {
        for (int x = max(0, x0 - 400); x < x0 + 400; x++) {
            positions.push_back(Vec(x * RACK_GRID_WIDTH, y * RACK_GRID_HEIGHT));
        }
    }

    // Sort possible positions by distance to the requested position
    std::sort(positions.begin(), positions.end(), [box](Vec a, Vec b) {
        return a.minus(box.pos).norm() < b.minus(box.pos).norm();
    });

    // Find a position that does not collide
    for (Vec position : positions) {
        Rect newBox = box;
        newBox.pos = position;
        if (requestModuleBox(m, newBox))
            return true;
    }
    return false;
}

Isn't this wonderful? Create an array of 12800 vectors, then sort it, computing more than 100k square roots (not counting other operations), then iterate over these vectors again until we find a non-overlapping position (requestModuleBox() will iterate over all the modules too each time) - and all this at 60 FPS when you just pressed a mouse button and didn not even move the cursor (and of course it can be done much faster and simpler when you do move)!

Of course, this is not the only place with such... um... coding style. On the bright side, now I know why modules are moving not quite as smooth as desired (on Tinker Board this mess drops FPS to less than 20 when dragging a module).

And even better news is that the overall low FPS I was experiencing on Tinker Board can be fixed by just using full-screen window. There's a bug in GPU driver, Xorg or somewhere. Anyway, I'll just default to fullscreen on ARM (Raspberry Pi doesn't have this problem but it won't hurt anyway) and won't have to work on running without an X server for now.

miRack - an optimised fork of VCVRack primarily targeting Raspberry Pi, ASUS Tinker Board and similar hardware. But will keep your desktop cooler too.

#miRack #VCVRack
·