Tiny Player version 2.0 is out now on iOS. This is a rather big update:
- Refreshed user interface
- Import from Files
- ZIP support
- Equalizer (high-shelf/low-shelf)
- Embedded lyrics
- Designated “incoming” folder
- Removed support for variable playback rate
- Removed “autosort” feature
- Requires iOS 15 or newer
If you like the app, you can use the new in-app tip jar.
Quick update: 2.0.1 is out:
- Drag playlist items to reorder
- Small fixes
Tiny Loader version 1.2.5 is out now. Tiny Loader is the companion Mac app for Tiny Player for iOS. This update brings support for Apple Silicon.
An updated version of Tiny Player for Mac is out now.
- Tweaked the main UI a little bit, extending the playlist to be edge-to-edge
- Added support for the mp4 file extension
Full changelog here.
The graphics backend rewrite took a while. However, the situation is now good.
- Sokol rendering works, uses Metal backend, iOS & Mac targets functional
- Sprite & font renderers rewritten, new render pipeline with fullscreen FX
- Game update & render loop rewritten
- Entity system simplified in major way
- Mobile version is now top priority, dual stick style
Next, I’m droping tilemaps and making entire maps in Blender. Everything is just one big texture. This gives me freedom in level design and saves work making tiles… tileable. Interactive elements will be placed using the in-game editor.
I export the rendered terrain from Blender as a RGBA image but with alpha value set to depth. So it’s RGBZ. The custom terrain shader uses the z-channel to draw water in lower areas of the level.
A small bugfix release of Tiny Player for Mac is out now. M3U files containing Windows \ path delimiters should be parsed correctly and the “Sudden termination” macOS feature is disabled to make sure the current playlist is saved properly.
Still at it with the Sokol migration and rewriting “some bits” of the game.
However, this activity has grown in scope and “some bits” now means I’ve touched almost every part of the codebase. I’m paring down many parts to make the game easier to tweak & debug.
I keep the Sokol implementation in a standalone project and keep switching between it and the full game, which still runs fine. At some point I will merge the two.
While migrating the rendering & platform code to Sokol I saw a lot of my own old code. It was clumsy and convoluted. That made me happy: I could do it better now.
Decided to start a clean re-implementation of buttons and menus. I broke up the logic into smaller functions. One for the hover & click. Another for timing, to enable animating the states. And another one for keyboard navigation. The old code had all this mangled together. The new version is easier to maintain, extend and reuse.
Also changed the rendering of geometry primitives in the UI to use SDF instead of the old 9-patch technique. Much better!
I will continue with a few other bits, here and there, see how that goes.
I’m porting my rendering code from OpenGL to the Sokol library. Sokol has a very nice low-level 3D API with multiple rendering backends (GL/Metal/D3D). It makes it much easier to experiment with new rendering techniques, especially when paired with the shader cross-compiler.
Still work in progress but I’ve done proof of concept tests for all major components of the game and everything seems to be OK.
I’m also using the Sokol app and audio libraries to completely replace SDL. The project feels much more lightweight without it.
For the last few years I had been using DigitalOcean to host this website & a few others, file sync and my git repos. Fairly low traffic stuff on a single VPS instance. It was nice and cheap. But still… the recent 20% price increase got me thinking…
Can I build my own server?
Turns out I could! And it was a lot of fun.
I used a 10th generation Intel NUC with a 6-core i7 CPU, 32GB RAM and a 1TB NVMe SSD. Yes, overkill. But the key parameter is power usage. The whole system draws ~7W at idle. What a wonderful little machine!
For the OS I decided to install Ubuntu (22.04 LTS). I’m familiar with it and it was useful having the same OS on both systems. Then, some housekeeping on the old server:
- removed old disconnected websites
- put websites under separate user accounts
- moved from Gogs to Gitea
- organized my git repositories
- setup a more thorough backup procedure
When I had everything ready, I brought the NUC to the new Prague data center and turned it on. It went online and the migration could begin. I started moving websites and services one by one. A few days later, the old VPS instance was empty and I turned it off.
||50GB + $extra
||6x CPU / 12 threads
There’s plenty of headroom for no extra money and I feel like I’m more self-reliant.
To elaborate a little bit on the backup procedure:
- daily rsync (soon → rsnapshot)
- daily mysql dumps
- /etc and apt package list versioned in git
- secondary NUC ready for deployment
- backup VPS account ready for deployment (prepaid credit)
- up-to-date checklist for configuring the whole software stack
It looks ridiculous when all enemies attack the player at once. And it’s frustrating. We need to globally throttle the attack rate.
Inspired by this fascinating Doom talk, I implemented a token system. Before each attack, enemies must acquire a token for it. After the attack and some cooldown period, the token goes back into the “free” pool.
Changing the number of available tokens for each attack type and tweaking the cooldown periods are an easy way to adjust overall difficulty.
The state of the token queue can be used to determine pressure on the player. This will be a useful input for the dynamic sountrack…