In 2025 I started my own fork of “M.A.R.S a ridiculous shooter”. A very fun, 2D spaceship flying game. I made 16 new weapons and many changes including few gameplay elements, more options and GUI.
📂Sources
Located here. List of my changes in changelog here.
📝Motivation
I think I played M.A.R.S. when it was still active around 2012. I liked it instantly. It reminded me of my oldest space games for 2 players, from around 1995 or so. Screens visible on this image on right, top under “2 player space games”, more info about that here. I
Long ago in the 90s, as a kid I did play the DOS game Ugh! untill end and I liked it.
Still in the 90s I did program a simple box flying game with a sinus wave below, for 2 players. Hitting each other for score. It’s even visible here on 1st screen under VGA 320 x 200. I even did start programming something similar to Ugh, it was called by me: Fly&Ants (also on screen here, far right side, middle row). It was meant to be Ugh style, of flying in 2D, but with a fly🪰 (looked more like a cow), that would transport ants🐜 between huts on trees. Yeah, it didn’t last long, but was a very nice demo. It featured a couple of new gameplay ideas: a cloud with rain🌧️ that pushed down, it had a thunder with lightning🌩️ sometimes, that could hit player. You could dive under that tree. And there was a new fountain⛲ with many particles. Including a type that was auto aiming at player. It did push away and you could float when directly over it. Also made scenery wet.
📝Motivation
In 2015 I played CaveExpress probably around when it was made.
In 2025, after years of being busy developing Stunt Rally, I played CaveExpress again, it felt a bit short. And I realized I can improve many gameplay things. The game is available on smartphones and in web browsers. Thus I think it was easier and slower for playing on smartphones with touch. IDK, didn’t try, I don’t need or own any😁. This felt less playable for me on PC, and also when compared to old Ugh. CaveExpress also features this new gameplay with box packages, to fly them to crusher (target). It has about 90 levels with this type. But had just a few with the Ugh type of transporting people between platforms (called Taxi here).
🔍Details
I first started by recoloring the existing Rock and Ice themes. IMO those were a bit dull and lacking color. I used Krita with many color or Hue curves. I didn’t know if it will be enough. But I did so turn brown Rock into green Jungle and gray-white Ice into orange Desert.
I looked around source code, to change gameplay to faster, and started commiting a lot of changes into my fork. I think I did make first PR with those 2 new sceneries. I saw some commits still, but didn’t know if after 10 years the original author will be still available or willing to change anything in the game. Yet it turned out great, even better than I expected. We quickly got into discussion and I did finish many changes this way, which went into original project repo. I also did a few bug fixes.
Details are in changelog at end, almost all (for 2.6) are my changes. I did make some smaller and nicer particles for snow weather, rain, wind, etc. I think less particles were meant for smartphones, but on PC having way more is not a problem and looks better.
New sceneries also inspired me to create many new maps. Some were based on Ugh levels (all Taxi type), others my original ideas. Now with 4 themes total, mixing them in one map, also made some maps more interesting. I also made a separate series of 24 letters (a few were already in Ugh), an original Desert series with pyramids and couple of mazes, a series of Races on big maps (including flood escapes) and Villages with both taxi and packages.
➡️Observations
I still have some new gameplay ideas to do, on Issues tab. Will see if I get them implemented. One more thing I’ll mention is CaveExpress source code. Many classes and interfaces. The game features multiplayer and this (I think) made the code more difficult (to read, understand and develop). I need to figure out how to implement things the way it requires, by sending messages, or doing things on client versus server side, even if it wouldn’t be needed at all for local play. So it is definitely a good C++ learning experience. And for contributing too, since I usually just develop my own projects. Lastly a nice break from the demanding, 3D, black hole of a project that Stunt Rally is.
Well it’s probably time I write something about how this goes, it’s been months already. I took about 5 years break from old Stunt Rally. I was occasionally playing and enjoying it, but also ignoring any flaws, and thinking hard not to get into developing it again more (well that’s also the way for any commercial software).
Forum Q&A👥
In January 2022, I started thinking of checking out the new rendering engine Ogre-Next and posted on Ogre forum my topic with many questions to get more knowledge about it’s state. I has been developed (and used) since years (probably 2015 or so) but I haven’t seen few key features like: Gui, fog, old plugin for grass, no demos for particles or water etc. Old Ogre had plenty. Ogre-Next had many, but not the very broad palette of game related components.
Terrain Demo⛰️
Shortly after I gave it a try and started a small demo (sources here) with nature scene. I was quite surprised by performance, how high and smooth Fps was with lots of vegetation. Contrary to old vegetation plugin we still use in old SR, which was also the worst thing, causing lags and delays while driving. But back then even fog wasn’t part of engine and had to be added with some knowledge. Luckily new Atmosphere component for fog and sun was made not long after.
No Gui
Since there was no working MyGui fork (was earlier) and all else was difficult, I didn’t move much further. Even though Ogre-Next is still technically Ogre, about half of everything in code changed. Even using terrain was completely different as the system was new. It was good since it has better performance but it also meant a lot more trouble to use it and later port Stunt Rally stuff into it, and we have an editor for it too and own custom blendmap I made with noise.
Continued
Half a year later in October 2022 I got back to my terrain demo, which was based on Ogre-Next terrain sample. Sources for it are there and I even made a gallery, it looked cool.
Gui🪟
I also managed to build MyGui with Ogre-Next (forum topic) and with some help continued its fork, after some trouble later, it was fixed and started working well. This was likely the key point to start porting SR, while also knowing particles work, and my demo works smooth with better Fps and no lags for vegetation.
SR3 start🚗
I then started porting SR still in Oct 2022 and calling it SR3 (3.0 was also latest Ogre-Next version). First by disabling almost everything in old SR code and making it build with Ogre-Next. Then by slowly restoring stuff one at a time and I mean really slowly.
Restoring stuff🌐
It took months and literally almost everything was causing trouble or not working at first in Ogre-Next. It’s like normal developing, I mean I code then test and fix it to work (yeah the old way, no unit tests, seriously). On top of that, there were few annoying new bugs due to how Ogre-Next works and needed something extra to fix, what was already working normally in Ogre before.
Fast forward⏩
In Feb 2023 MyGui started working and could be used in SR3. Worse still, during my endless forum topic we found many bugs in Ogre-Next too. It’s like half of my problems end in one. A bit disappointing TBH, but that’s the way with software nowadays. It’s buggy and needs updates constantly. Which brings me to support aspect. If it was great I wouldn’t mind. And mostly it was, but lately I’m waiting 1-3 weeks for response and have many ongoing issues and unanswered questions. It’s a pity that it’s just (putting all contributors aside) mostly a one man’s project. Kind of like with SR too, especially after that one year when there were more programmers.
Water🌊, Effects
Last major features were: water and effects (like SSAO), probably the biggest thing. Worse still, it wasn’t developed by me, but mostly by scrawl (and others) back in 2013 or so. So I had to redo another thing in Ogre-Next by myself now. It was difficult but good learning experience. HLMS shaders, are big, complicated, have lots of code and variations, and yeah it’s much more difficult than just using a shader editor and putting together blocks or just installing a water add-on. We still are missing a few essential ones like: soft particles and HDR with bloom, that old SR had around 2013 already.
📊Other engines
Well this section might be of use and have some info. Not just SR3 history like above. Meanwhile I did think about other engines and shortly looked at 3 of them. There is a big list on wiki too. And I did recently write a tutorial page on CG graphics its Engines section could be better too.
This is my personal view, and let’s keep in mind that I did look at them after SR was already made (took 5 years) and it has its own track / map editor made by me. It is FOSS too.
Unity
Bit older than UE I guess but also a huge hub for commercial stuff. Even the tutorial mini game had paid crap one could buy for it. That’s really the first thing that pops out instantly for me. I do hate commercial stuff. I guess you could find something “free” but its like looking for free money in city, roughly for me. It will only be a free commercial for paid stuff. Sure you can find stuff made already like rivers, vegetation and what not but given that this has a price, it’s instantly not for me. And it never has any other license than “you can only use it for Unity”.
UE5
This thing certainly got on my nerves. Turns out I don’t even have a PC for it. I started by trying to download. Nope, you need to get full sources with deps and then build them on Linux. I tried few times before I realized this needs over 100GB to complete IIRC. Yeah my SDD with OS is still just 128GB and the one new I got has just 512GB and doesn’t really have that much free space.
Whatever, the next thing was a real killer for me. When it finally started (after building for hours) it showed a tiny logo with a tiny text showing that it needs to build shaders, over 4000 of them. I can’t even. And it did compile them on like 6 CPU cores for 30 minutes. Seriously WTF.. and I don’t even use this term. I don’t know for sure, but it wasn’t just once that it had to do this. I remember few times that “building all shaders” time waste, possibly even on each new project created or so.
Well then I realized my PC (with 12 year old CPU) isn’t even in same era, UE5 would need you to first spend a lot of money for PC with latest hardware.. to probably still take a long to even start. Needless to say it is also a huge hub for commercial add-ons etc.
If we look at SR which has over 200 tracks already and on average 1 of them is just 5MB, not GB we can see the huge gap. One demo in UE5 was 100GB.
Godot
I was pleasantly surprised to find waterways plugin for rivers and also seeing it’s MIT license. Feels like the proper way of doing stuff for FLOSS software and games like SR3. Would be nice to have it in SR for sure, but at least I can learn from it and even use sources if I ever find the time for this. Well, getting back to Godot, it’s big, I don’t have much of experience. It has its way of doing things and may be even extended. But let me sum this all up next.
Common
So let’s end this quick look around. Each game engine has lots of stuff. And I can’t even judge how long would I need to learn it, to estimate how long it would need, to port SR to it (any engine). And how would loading tracks look in it, or how much more complicated editing them would be. I’m pretty sure it’d be a waste of time and effort. As for game simulation, I guess I could build as a DLL or something to run in it, but that just doesn’t feel right at all. I mean what for, so that I could use engine’s features sure, but I’d need to waste a lot of time (in total) for starting it, clicking everywhere, etc. Lastly learning its issues and their solutions. Every big engine has something specific to it and problems with some things for sure. Meanwhile I already had a lot of code written to do what and exactly how I wanted it to be, e.g. editor for creating SR tracks.
🟢Ogre-Next
❔Is it good for you?
Obviously it depends. It is a rendering (by rasterization) engine only. So contrary to the game engines listed above, you don’t get anything beside rendering, i.e. no physics (e.g. bullet), no sound (e.g. openal), GUI, scripting, network etc.
It is for advanced users / programmers. This means you need advanced programming skills to use it fully. Right now I also believe it means you need to find bugs in it yourself too. Surely there are some still and the more I use it the more I find. And I’d expect it to have none OFC, sadly that’s not possible.
There is documentation for it, but I can’t say it is covering all topics you might need. Some features I needed later had solutions that needed to be found in older forum topics. This wasn’t easy since they’re old and I don’t know if it’s still valid and there is also plenty of unneeded text in posts. And support? Yeah it’s nice and great when it happens but otherwise you’re left alone with it. I also can’t say it’s popular. Seems it was much more earlier around 2010 and also the Ogre 1.x version is still more popular.
Good things last, it surely has many features, modern ones too like few types of GI, HLMS shaders, etc. It is low level, meaning it can give you more control and optimization. But I don’t have any comparison here, I haven’t used any other just older Ogre. Surely there are others, eg. bgfx.
✅Why I use it
The biggest reason is really simple. I made SR in Ogre so moving to Ogre-Next sounded like least effort. Surely old Ogre changed and I got myself stuck to shiny material generator which again scrawl wrote back in 2013 or so. Meanwhile RTSS shaders got better in Ogre, and lately even got auto instancing. I decided to skip all that and make a bigger step, biggest possible for better hardware and that was using latest Ogre-Next. Even with few things or components missing. It also featured auto instancing by itself which I liked most, secondly the new terrain has less batches too (more performance).
This is a notable but short entry, not much of a project, rather a contribution. I developed an Exporter code in Stunt Rally 3 Track Editor allowing tracks export for Rigs of Rods (also FOSS game). BTW also gathered many (CC licensed) assets from SR for use in RoR.
📷Screenshots gallery from many tracks start here on RoR forum topic. Also older WIP here.
▶️Videohere Shows drive in RoR on one SR track and at end (somewhat outdated) Gui for Export in SR3 Track Editor.
Documentation here. Explaining differences and how to use SR3 Export for SR or own made tracks for RoR.
🔍Details
I first noticed some interest in this topic. It also has a lot more detail in my posts, screens, and RoR bugs listed too. There wasn’t a lot of interest, so it was actually much more a challenge for me to try. And well it consumed me for like 3 weeks. A lot of C++ coding (76 kB in total) for that Export functionality and even my hands started hurting after (was too much typing late into nights). The Export also allows others to create tracks for RoR using our SR3 Track Editor.
Finally 130 tracks from SR are available in RoR, so about 55% from 229. Is quite significant at once I think. It was also a lot of fun to drive SR tracks in RoR simulation and BTW learn about RoR code and people involved. Of course I got back to developing SR3 after.
This is a project I started to learn and test newer version of Ogre rendering engine: Ogre-Next. Later I moved Stunt Rally 3 to use the engine too. Now also a showcase for nature scene rendering using the engine.
Available here. Licensed: MIT. Unlike my other projects, where I choose GPLv3 that requires releasing modifications, under same license.
It has no Gui or other dependencies and should be easy to build.
🔍Details
At first it was a project to test Ogre-Next and code needed to get things done in it. Surprisingly half (or more) is done different way than in Ogre. But I am also surprised by better performance and optimizations done by the engine.
It is also a good tool to test and fix bugs in Ogre-Next, e.g. many for planar reflections used for water.
Recently I also updated it with some media from Stunt Rally 3 to make it look better and be a showcase.
New implementation of my audio player, based on my older cAmp. Works on GNU/Linux (and should on Windows). Now using SFML for graphics, and ImGui for the new GUI. Still using (not FOSS) bass for audio.
📂Sources
Available here. Now with CMake and newer C++17 syntax.
📷Gallery
Screenshots here. Starts with normal playlist, find, track backgrounds explanation with time coloring, tabs adjust, later 3 visualizations, their themes, and rest of Gui windows.
✍️Motivation
Old cAmp was WinAPI and DirectX only and had bad style, old C++03 too. It was still one of my last college projects. I did once try moving it to SFML, and almost succeeded. I had no pressing motivation until I started moving to Debian GNU/Linux instead of Windows which required this new version. I made things differently this time and with more experience, hence the Gui and visible options.
Missing Features
The old cAmp was using GPU shaders and cAmp2 doesn’t use them yet. Seems not that needed. And it doesn’t even have hotkeys or threads implemented here. Well there is always something on my “to do” list for this project, like for any other.
📊New Features
Apart from most of the old features (with few important missing) it has some new ones too.
Most notable addition is the Gui with few windows having controls for changing view parameters, adjusting with sliders or showing info. Since ImGui is such a joy to use it was also easy to implement bindable all program keys list and move all options to Gui.
Other new features:
Colored tabs, sliders for their background and text brightness. Empty tabs as separators. Can be seen on screens. I find it quite useful, e.g. for now I have 4 rows, first is for Trance style, 2nd for older trance, 3rd for rock, 4th for metal genres (about 31 playlists total).
In between markers. E.g. if I filter tracks so that playing cursor or find matches become not visible then it draws a shorter marker still, to show they are between those visible. (It’s best shown on 2nd screenshot also 3rd and this).
New visualization type (screens, parameters): FFT above and spectrogram below.
Queue tab(s). Any tab can be set as queue. It will be marked in 4 corners. Then you can add tracks with one key (E) to queue end. Good for temporary playlists or “best of” ones.
⌛Conclusions
Well it is definitely useful. It’s one of those key programs I need to have at start of any OS (first is my DoubleCmd fork, then this player, 3rd is Firefox with many add-ons). Yet it’s still missing one crucial feature like moving (reordering) tracks. Kind of funny, but I still don’t need it that much. I just delete whole playlist and add its main folder again to refresh once a while, and keep order in my filenames and subdirs. There are few other features missing too from previous version. But if I’m doing bigger projects (like Stunt Rally 3) or smaller and more interesting ones, then I don’t have time for this nice useful program which I still use every day. If we count the older one too, made in 2009, this would be the longest used program I made.
This is a nice gadget I made recently for controlling speed / power of my PC fans (all are 12cm, 12V, 3 pin, with RPM output). It has way more features than my old & basic 3 knob regulator which I used for over 15 years. And since this is open source (and I wrote it), it surely has and can have any feature (commercially unavailable, not even thought of, or way too expensive). Obviously it isn’t badly needed, that’s why I made it after so long.
I do not recommend Teensy 3 at all. All Teensy boards are quite expensive and aren’t that needed for a fan controller. I think a bluepill or blackpill would suffice and be much cheaper. More info and detail in my MCU tutorial. I simply used Teensy 3 since I had it available, doing nothing and I had code for it from my older keyboard firmware, so it was faster to adapt it.
✍️Motivation
For many years I was using just the simplest LM317T voltage regulators with 3 knobs (for 3 fan sets).
Obviously a basic analog fan controller is very simple and extremely useful. I had 3 knobs (5k logarithmic potentiometers) with LM317T (even with no capacitors or radiators), mounted in the 3½” floppy disk bay. It was working very well for years and I could still use it.
I did try once a Gelid Speedtouch 6, wasn’t very cheap, and it was hopeless. Even worse, when I realized that I can make a better one myself, like usually. Additionally, after being rather finished with my keyboard features, I had some Teensy 3.2 boards left, lying around, doing nothing, simply asking to be used for something. Even better, I could use my older keyboard firmware for Teensy 3.2 and adapt it fast for this controller.
So I finally got to creating it. I called it “Fancy” from Fan C(ontroller). There was something new to learn too. I even used a cool circuit simulator to find out resistors around transistor, wasn’t exactly the real value later though.
And of course not everything went as planned.
For example: I wanted to use thermocouples for temperature which I had few of already. I tried an op-amp with differential amplifier for them and used ADC to read voltage which seemed working on breadboard. But after doing that for real (and using bigger resistor values) something didn’t work and I saw noise. So after few days trying I dropped it and just used DS18B20. They are bigger (3pin package) but have more precise measurement (at higher cost too).
Unfortunately I also killed one Teensy 3.2 board by accident. I’m not even sure how. I’m guessing some 12V was still left on capacitors and I could touch 3.3V pins with it.
📊Features
A shorter, bulleted list of all features can be seen in sources readme with more detail on electronic parts and schematic (image here).
GUI
It has a 3×3 keyboard and a LCD color display (diagonal is 1.8″, 4.5 cm). I did years ago my keyboards this way, so it also came with 3 levels menu (GUI), many options and even full screen demos (why not). Of course it permanently saves all settings, in EEPROM.
📈Regulating
The main advantage of my digital fan controller is that it allows lower RPM than analog, which then makes PC slightly quieter. This is because a fan needs shortly higher power (voltage or PWM) to start, but can have it lower after it started rotating (I don’t mean the power started rotating ?).
Next, it monitors RPM (revolutions per minute). So a natural safety feature here is: stop prevention (or in general RPM guard). It can increase power shortly to start again, even if user picked too little power to spin, or something stopped the fan.
Additionally PWM outputs can be used, for fans that allow it. Actually all of my old PC fans didn’t work with PWM, so I had to also make analog outputs (channels) for them at some point. I don’t know if it could be more universal, these channels require some other parts. So it can control analog fans (changing constant voltage) and PWM fans (changing modulated pulse width at medium frequency).
Optionally, temperature is measured. It can be used as feedback to automatically set fan power. This is naturally useful if sensor is on (or near) the heating part which fan is cooling. Sure, this can be possible to do with some software, that came with PC motherboard, GPU or a separate program. But it may not work on Linux or have all of my custom features. During summer I had my fans set higher, also even did set them lower when I wasn’t using much CPU (e.g. playing games or building C++). So hopefully this feature will make controller do it now, not me.
Since the display is 160×128 pixels, it can show graphs of RPM or Temperature over time. Even few smaller at once, but with less detail.
⌛Conclusions
Well it was a cool project, not just with digital chips, I had to use transistors with other parts too. I’m glad that one of the boards I have unused got to do something everyday. I hope it will last long. After all, my old regulators were really basic and much easier to repair (which wasn’t needed). Surely this thing is heavy, probably has too many parts too, but it doesn’t matter. It’s not like my PC weight matters at all.
This is my newest keyboard controller software (based on my previous one) used in my keyboard CK9 (upgraded CK6), running on Teensy 4.0 with a 2.8″ color LCD display (320×240, ILI9341 chip).
Here are videos of keyboard CK9, showing most of K.C.4 on its display:
View – Short video of keyboard and closeup at display.
Demos – Showing all demos (in auto mode): Plasma, 3D Polyhedrons with diagonals, Wave, Fire (meh), 2D waving CK Logo with shadow, and old Rain.
Features – A detailed look at features, no voice or commentary though. Editing mappings, sequences, testing etc.
Link to my channel with all keyboard videos so far here.
📂Sources
My firmware sources are on github. It’s called K.C.4 (“Kacey”) simply from Keyboard Controller and 4 from Teensy version.
The readme with all key features is visible on github. Here is more practical description. At end of page I wrote a comparison from my previous version (for Teensy 3.2) and quickly with other controllers / keyboards.
📊Features
The current code features are (and were mostly present in my previous K.C. version):
Display with menu, where you can edit everything possible.
Mapping (key binding). So which USB code will the physical key send to PC when pressed. There is a pick list with all common keys (and internal functions, sequences, etc) to choose from when binding. It has group colors and group filter for easier orientation.
Keyboard layout drawn on display. Shown when editing mappings (for currently chosen layer). Has a cursor to move around between keys. It’s also possible to jump to a key by pressing it.
Layers. If you hold a key, whole keyboard layout changes giving you other keys. Kind of like the Fn keys on laptop but much more useful and customizable. A common feature of custom controllers. Locking layers is also possible, either by lock/unlock key, tapping layer key fast or holding it for longer. Of course can be disabled and delay parameters are changeable.
Mouse keys. Keys that will move mouse, press mouse buttons or scroll mouse wheel. Also featuring acceleration with parameters for it and speed in GUI.
Sequences aka Macros. Basically any key combinations (for key shortcuts) and any sequences of key presses (for e.g. passwords). I am showing sequence previews where possible too, so when editing Mappings (for a sequence key), when picking a key from list or Testing pressed keys (if a key runs a sequence). I am also showing in sequences View, all mapped keys that run selected sequence.
Sequence commands are just a further extension.
They are special commands (beside sequence keys), that e.g. wait for few seconds (0.1s resolution), or change how slow the sequence will run (1ms resolution, useful e.g. for putty).
Others allow putting comments (for sequence purpose), and hiding sequence from preview (e.g. for passwords).
There is also a command to run other sequence(s) from this one. Also a repeat command that will do sequence (keys) continuously, until interrupted. This is e.g. useful e.g. if you want to watch a video faster, skipping parts with arrow keys after a short delay or take screenshots while watching etc. Normal keys can be used when a sequence runs too.
All mouse actions are available as commands too. So for example you can press a key (for a sequence) that will press button or move mouse etc. I have this way a mouse gesture done.
Internal functions. Keys to e.g. dim brightness, toggle GUI, toggle LED light, quit sequence, lock/unlock layer, change default layer etc. This a direct way, faster than adjusting parameters in GUI.
Testing and Setup pages. Useful when developing and to check if everything is working properly. Scan setup is advanced and adjust which strobe delay, scan frequency, debounce time I need. Matrix page shows the 18×8 keyboard matrix, with my anti-ghosting code working and any issues from too low strobe delay. It now also features X marks on keys that are available in matrix but not present on layout, this makes locating new extra keys very easy.
Demos and Game. Were already present in previous version and even on the first tiny display I used (128×64 mono). Since I have a display, and a powerful MCU, they show their drawing possibilities. They got extended to new resolution with few added extras. Best shown on videos, links below.
Clock. With date (uses internal RTC, needs 3V battery). Also showing Temperature, read from attached DS18B20 1-wire sensor (optional).
Statistics. Clock also displays (on its extended pages) keyboard use statistics:
Uptime. Time since power on or plugged in USB.
Late hour background. Will start slowly showing top of display orange at 22:00 and every 0:30 min going more visible, being yellow after 0:00 (midnight). This is to notify and motivate me to go to sleep when I sit too long at night.
Active time. I.e. how long I use keyboard without a break (at least 5 min, can be adjusted). Changes color from value. This is helpful to know if I’m doing something too long on PC. After all, it is recommended to take 5 min breaks every hour, it is healthy for spine and hands.
Inactive time. The opposite. Useful to know how long was I away from PC (keyboard). Also changes color when over 1 hour. Meaning I probably should have turned it off, to save power.
Press/min. Typing frequency, so how much key presses are done every minute. A colored value on left, going e.g. red at 120, yellow starting at 50. Also a second value below with total average since power on, with slowly changed value. So it is useful and directly corresponds to how tired will hands be. It’d be great to keep this value below 50, but sadly writing any text (e.g. chat, email etc.) or playing a game makes it go even above 150.
Graphs. As a part of clock, they show history of using keyboard (key presses/minute in the past hours). Second one is for temperature history. There are 320 points on display width and parameters for how often a value is added to graph.
⌨️Keyboard CK9
I upgraded my 2018 keyboard CK6 with this bigger display and K.C.4 and it became CK9. I also added tiny extra keys, lots of them. Above Numpad, 2 rows of 8 or in other words 4 groups of 4. Surely will come handy for e.g. internal functions or could be extra F13-F24 keys for OS. The keyboard has visible tear on few keys already, well I use it since 2016 (was CK3 first). Nothing yet, compared to the 14 year old one (CK7/4/2).
✍️Motivation
My previous version of KC and keyboards with it were quite useful and the 1.8″ color display was good too. The keyboard drawn on screen was minimal. Keys with one letter/digit/symbol had a 5×7 font, but 2 letters needed a tiny 3×5 font. It worked, but didn’t look great. So the new display is bigger 2.8″ and has about 2x resolution (320×240 vs 160×128).
The main reason for this upgrade though was the new Teensy 4.0 with a MCU that runs at 600MHz. It seems to be the fastest one available (on a board with USB, ready to use). And is even way faster than all previous. I already didn’t like Arduino in 2014 when I got interested in MCUs (again), seemed like a stone age relic compared to Teensy 3, but today I can say they probably have computational power of a rock, when compared.
The result is constant 45 frames per second almost always. This is what 600MHz MCU with SPI set at 60MHz for this display does, while using DMA for transfers and double buffered drawing (one buffer is being sent by DMA to display, while MCU draws new frame in second buffer, at the same time).
⚖️Comparisons
Of course, there were many projects of using a big display with slow MCU even. A MCU not having enough RAM for screen buffer. But this means very low refresh rate (low Fps) and flickering (blinking when redrawn).
There are few open source keyboard controllers, I think none of them even have a display, and some still use ATmega 8bit MCUs. Their requirements for program and RAM (memories of a MCU) are minimal, way lower than mine. And the price will be lower too. But the main flaw coming from it, is having to compile on PC and upload to MCU after any change. This is a big nope for me.
📢Rants
So for me, this is now the present (not the future anymore). And well honestly, whenever I see a custom keyboard picture I’m just asking: “where’s the display?”. In addition, seeing Cherry MX or any switches turns me away immediately.
Because there is one more very important thing that is the light press modification. All my keyboards since 2005 have it and it’s just the default for me. Sadly all commercial keyboards are garbage in this matter and people continue to produce keyboards that have a tactile feel, 4mm travel and around 50 gram force to press. Well for me this is the middle ages era. This can cause injuries (Carpal Tunnel Syndrome). And I guess it feels awful for those having pain from using such keyboards.
For my modding process (of reducing rubber dome keys press force and travel) pictures are in this gallery and I made a video of it recently (it is CK5).
✅Summary table
For reference, here is a table with current status of all my keyboards, since start until present day:
Name
Assembly year
Original keyboard
Keys actuation
[gram force]
Notes
CK3 > CK6 > CK9
2016 > 2018 > 2020
A4 Tech KX-100
23 g
Cheaper, bit wobbly, but more keys
CK2 > CK4 > CK7
2005 > 2016 > 2018
Logitech Ultra X Flat
33 g
Stiff foil, old, extra keys
CK5, CK5b
2015, 2020
A4 Tech KV-300H
9-18 g
The lightest foil
CK1
2004
Logitech Ultra X Flat
25 g
First, old, had extra keys,
now only for testing, 1 row dead 💀
This is my own keyboard controller software used in my keyboards CK6 and CK7 (upgraded CK3 and CK4), running on Teensy 3.2 (or 3.1) with a color LCD display (160×128, ST7735 chip). It is continued in newer version with Teensy 4 and bigger display.
My firmware sources are here. I called it K.C. (aka “Kacey”) simply from Keyboard Controller. A catchy cool name for software is a thing, isn’t it.
The readme with all key features is visible on github too. Here will be a more practical description.
✍️Motivation
My previous keyboards CK3 and CK4 were quite useful. But there were few flaws that I wanted to improve. They had a very tiny display, sure it did the job, but wasn’t convenient to look at for longer. Since I based my code on existing kiibohd controller software, there were few problems. Any change in key bindings had to be done on PC, needed to build binary and upload it to MCU. That’s a long way to e.g. check if it’d be better if I swapped some keys. Not to mention doing it at work. Lastly, there were few bugs which I couldn’t spend more time trying to fix.
So, it’d be better indeed to start writing my own code. And that’s what I did. Right now I can’t find a reason not to use my controller code. Sure, it was easier back then to get started, knowing there is an open source keyboard controller and it runs on Teensy 3.1, this is how I got into it. My code surely doesn’t have stuff present in kiibohd like NKRO support, keyboard LEDs animations and other fancy things I will likely never need. But it now does have features I wanted and it wasn’t that difficult to code them.
📊Features
So the code features are:
Display with menu, where you can edit everything possible (that I needed so far).
Key bindings (mappings), i.e. what USB codes will the physical key send to PC when pressed. There is a pick list with all common keys (and internal functions) to choose from when binding. It has group colors and group filter for easier orientation.
Keyboard layout drawn on display. Shown when editing mappings. Has a cursor to move around between keys, can also jump to key by pressing it.
Layers. If you hold a key, whole keyboard layout changes giving you other keys. Kind of like the Fn keys on laptop but much more useful and customizable. Surely a common feature in custom controllers (like tmk or kiibohd).
Sequences aka Macros. Basically any key combinations (for key shortcuts) and any sequences of key presses (for e.g. passwords). Not typing passwords myself, when my keyboard could do it, was my first reason when starting with keyboard controllers back then. Sadly even in kiibohd you couldn’t change them without rebuild and upload. This then was possible in my fork of kiibohd. To be convenient, I am showing (short) sequence preview where possible. So when editing Mapping (for a sequence key), when picking a key from list or Testing pressed keys (if a key runs a sequence). I am also showing in sequences view any mapped keys that run selected sequence.
Sequence commands are an even further extension. If you have an editor on display (basically a simpler editbox) one could put special commands (beside sequence keys), that e.g. wait for few seconds, or change how slow the sequence will run (useful for putty). Newest ones allow putting comments, useful if you have lots of sequences and want to rather see what it’s for, not what it will press. And hiding sequence from preview, useful if you don’t want to show important passwords on GUI.
Mouse keys, i.e. keys that will move mouse, press mouse buttons or scroll mouse wheel. Also featuring acceleration and even parameters for it and speed in GUI.
I now even have mouse commands with all mouse actions possible to add in sequences. Some stupid programs don’t allow everything using keyboard and specifically want you to click with mouse. But hey, now even this could be done automagically by my keyboard.
Testing and Setup pages. Those are quite useful when developing and in normal use to check if everything is working properly as intended. Scan setup is nice e.g. to check which strobe delay, scan frequency, debounce time I need. Matrix page shows the 18×8 keyboard matrix, with my anti-ghosting code working and any issues from too low strobe delay.
Demos and Game. Were already present in my fork of kiibohd. Now extended with new presets to color display. Best shown on videos, links below.
Clock with date (internal RTC, needs 3V battery) optionally also showing Temperature, read from attached DS18B20 1-wire sensor.
Internal functions, e.g. to dim brightness or toggle GUI, by keys on other layer.
⌨️Keyboards CK6 and CK7
I then upgraded my 2016 keyboards CK3 and CK4 with bigger, color display (160×128 LCD, ST7735) and K.C. They now became CK6 and CK7. Apart from the new displays and my software, the keyboards are the same.
The CK7 is the oldest one, comes from CK4, which in fact was done from CK2 (2006) and is now 12 years old… Still doing fine. Well this proves then, that cutting and gluing rubber domes is nothing that would decrease the lifespan of a keyboard. Even recently folded keyboard foil since CK4 works okay.
▶️Videos
There are a few videos of my keyboard CK7, showing most of K.C. on its display:
View – Short video of keyboard and closeup at display.
Plasma – Quick and colorful show of presets of plasma fullscreen effect. It runs at 10-30 frames per second. Note that I overclocked Teensy 3.2 here at 120 MHz, HW SPI runs at 30MHz. My other keyboard CK6 has Teensy 3.1 at 144MHz, SPI at 24MHz, it gives about 1.5 Fps more here.
Demos – Showing rest of demos: 3D Polyhedrons with diagonals, Wave, Fire (not real) and the older ones: 2D waving CK Logo, Space, Balls, Fountain, Fonts.
Game – falling blocks (Sixtis), or my version of it. It has 11 game presets, generated blocks, possibly diagonal, with many parameters for custom games.
Features – A detailed look at features, no sound or descriptions though. Editing mappings, sequences, testing etc.
Link to my channel with electronics videos here, just from my keyboards.
☑️Summary
For reference, here is a table with current status of all my keyboards, since start until present day:
Name
Assembly year
Original keyboard
Keys actuation
[gram force]
Notes
CK3 > CK6 > CK9
2016 > 2018 > 2020
A4 Tech KX-100
23 g
Cheaper, bit wobbly, but more keys
CK2 > CK4 > CK7
2005 > 2016 > 2018
Logitech Ultra X Flat
33 g
Stiff foil, old, extra keys
CK5, CK5b
2015, 2020
A4 Tech KV-300H
9-18 g
The lightest foil
CK1
2004
Logitech Ultra X Flat
25 g
First, old, had extra keys,
now only for testing, 1 row dead 💀
This is a program I wrote specifically to aid in managing my coloring patterns in file managers. For both Double Commander and Total Commander.
📜History
I was using Total Commander since about 1999, back when it was called Windows Commander. Since then I’ve gathered an already quite big list of file extensions for own coloring. The list even has colors for directories and my own rating symbols.
I’m using Double Commander more now and having my list in it is essential. It also needs a bit of order changing to have similar result in both. E.g. for directories, links, executables. I also started a fork of DC with my own tweaks.
✍️Motivation
Because both commanders are clunky at managing such big lists, I’ve decided to write my own program that will allow doing it efficiently and fast. And by the way it will be usable for both commanders. This way I can now just use it and get my list exported directly into each commander’s settings files, without editing it there at all.
🔍Implementation
The program is written in modern C++11. It was a good step forward into learning it in practice, since all my previous programs and games were tied to C++03. Since I also switched to using GCC, more recent C++ features are available.
It uses SFML library, which allows easily having windows, graphics, shaders, threads, sounds etc. So without too much code and while also being cross platform. Which is important to let me use my own programs on GNU/Linux too.
Gui
I started using SFML already a few years back. But only for drawing text. This time I went further and looked around for a GUI system for SFML. I checked out SFGui and TGui which are good, have themes, most controls, but other that that are basic and need a lot of code for simplest things, same like e.g. MyGui did.
So my interest settled with ImGui which has an abundance of possible Gui controls and demos (on first page, and even more in topics). It is famous for debug panels in games and even is used in editors for games. The main downsides are no texturing of controls (just one color) and no editor for layout. Since you just create it in code, where also events are handled. This immediate mode approach is interesting and allows quick developing. Of course not for each purpose. For use with SFML it needs a helper library ImGui-SFML.
📖Tutorials
I’ve put it all together with CMake and using Qt Creator as IDE. This will probably serve as a base for many of my programs. It is easy to compile on GNU/Linux, as it needs only SFML installed, rest is in source code. To get started using it, you can see the SFML tutorials, the tutorial(s) on connecting SFML with ImGui and my tutorials for CKeys program (earliest 3 releases here). Later checking out the ImGui demo program’s code when needed.
The program’s code quickly got bigger and rich with features. Some are still missing but there already are many features that allow fast and pleasant editing, which aren’t present in those commanders. For example:
sliders for R,G,B colors.
scaling font size
pattern search with occurrences mark, also on slider
groups, visibility, etc.
Also convenient are hiding, toggling directory and newly introduced groups. Groups allow putting lines with patterns together with a title and then e.g. hiding it. Later I added also visibility sets for groups, allowing to easily create other views for list. E.g. basic (public) and detailed (with my custom patterns e.g for Stunt Rally or OGRE files).
The program also has some settings, saved in XML and visible on Settings tab. It also features a Help screen with all shortcuts.
Projects made in it are saved as own XML format (using TinyXML2), where each pattern (or group) is one line. This allows easy comparing (with diff viewers) with earlier projects, and merging some changes.
