Category: Demos🔮

  • 2024 Unreal Engine 5 tryout

    2024 Unreal Engine 5 tryout

    ⏱️Overview

    I’ve spend over 1 month in total, exploring the Unreal Engine 5.3 on Linux and gathered some opinions about it. I’ll say upfront: I don’t really like it and this version is not even fully working on Linux. And no: I will not make or port Stunt Rally to it, I know for sure now. This isn’t a strict tutorial, but my gathered experience, many complaints, with some useful links.

    📂Gallery🏞️

    Short gallery with showcase here.
    Long gallery with many more things shown and including visible bugs.

    ✍️Motivation

    Well I have been using Ogre rendering engine since about 2007. Over a year ago moved to OgreNext, which is even less popular. I can simply say there is just one person (the developer) who is able to, and does usually answer my questions, or fixes issues.

    Naturally at some point I wanted to get at least a basic knowledge of other engines. Since they’re so highly popular and have big forums and communities. And get my own opinion, also regarding what’s best for Stunt Rally (rendering only since we already have simulation and even own track editor).

    I made 3 initial choices due to highest popularity: Unreal, Unity, Godot.
    I did already check them in 2022, and wrote a little in my Rendering “tutorial”. But ultimately for me, Unity died a sudden death due to their freaking license changes (which shocked lots of developers and made them move). I did check out Godot and so far its best demo for terrain and nature, and it didn’t seem too great at performing there. Which seems also a popular opinion that it doesn’t handle big 3D scenes that well.

    So, the goal was not really to move SR to any of them. It was to assess if that’d be even reasonable, and logically prove that it’s not (even only for rendering purpose). Last and quite important reason was to learn “the other side”, new effects and technologies, and know what would be possible to achieve in SR too (someday).

    📜Earlier try

    I did try UE on my old PC. Back then in 2020, UE5 had to be built from sources on Linux. Took me like 50 GB of space to download. And few tries to finish, as there was no info (and I had a small SSD). Then few hours to even build. Lastly at start it took 30 min to compile over 5000 freaking shaders. So ugh, yeah, clearly my PC was too old for UE5. I did try later after I bought a new PC. It does still need 5 min for shaders now. And that’s needed when major options are changed.
    Still, my impression is that most people would need to buy a new PC to use UE5, unless they already got a new gaming PC. It is really demanding on hardware.

    🔍Observations, Issues

    Of course, these are specific to me, using it on Linux. Also to what I was testing: for Stunt Rally try, so in 3D, mainly for driving cars, on gravel and for stunts.
    Also I didn’t spend years using UE just maybe over 1 month total. I could be wrong, or assumed something using my anti-commercial logic, or just didn’t care to investigate longer.

    I list here all my issues I had using UE5.

    • UE is a big commercial hub, feels like a shop. Not for true FOSS projects. Lots of assets, meant to be used for Unreal projects only. Nothing is CC Licensed. They also have own binary file format for everything, only .ini readable for options. I did import e.g. trees from .fbx (which can be exported from Blender) but that needed more work, making materials later.
    • Aimed at Windows and making big profits. Obviously if someone paid for Windows, they’re more likely to pay for its software. Linux is the least popular so least supported.
    • Not meant to be used on Linux only. Nothing can be downloaded, as this needs the freaking Launcher application which has only msi installer. Even their demos don’t support Linux, e.g. this and that. Thus IMO they don’t fully support Linux, just wanted to add it to platforms list, as only the engine works but not the rest of their ecosystem. The Quixel Bridge is also not working at all. I don’t care about that integration, to add assets directly to project content. I’m a fan of simple download buttons or repositories. But big companies progress by buying other companies and so “improving”, which is also a way to be more monopolistic.
    • Editor GUI. IMO it’s utter garbage and a mess. I wouldn’t enjoy using it daily. There is a “magical” way to scale whole GUI. But no real options to choose font sizes, icons, themes or other visual stuff. Seriously, in such a big editor, used by so many people every day? Sounds like a joke to me. I can’t take seriously any* programs which don’t allow user to (at least) change their theme and font size. *even small, but except my own. I have made my own themes for every software I used for longer.
    • Tons of properties, written in same tiny, plain text, no idea which important, no icons for settings or e.g. even colors or bigger fonts for more important/significant ones. No way to bookmark properties or settings to know which I want to remember easily. Should I like write them on paper or something like in middle ages, or remember all that? Some have tooltips (white) with decent text, some very little. At least the worst stuff is bottom in properties usually. And the (rhi) statistics texts are even smaller and less readable. I made my own Fps and statistics bar in SR and it has few detail modes now, medium size font, and even coloring from value, if it’s red that’s bad.
    • Editing terrain. Seriously cumbersome. If you ever seen or used Stunt Rally Track Editor, it should be pretty clear what I mean. Sure, I wrote it myself so it has what I find best already. I mean using just mouse wheel to adjust brush size and force. Also having keys that increase those. Then plenty of terrain brushes to choose from. All brushes using floats and computed for needed size. I could go on. We made over 200 tracks just using those tools. Seems like UE doesn’t care much about such tools. There are some other software programs (big and commercial too) that will make a terrain which you can import instead of editing. BTW I saw no way to import raw float heightmaps which we use since years for best quality.
    • Gizmo. Well it may be my personal hatred for that thing. But how am I supposed to drag that one axis if it’s covered by another. Probably need to focus, rotate around or use ctrl, meh. We don’t have a gizmo in SR editor, yes it may not be obvious how you’ll move etc, but you’ll always be able to do it, directly from anywhere.
    • Physics. I’ve seen some opinions on internet that it got worse in UE5 (has Chaos), from UE4 (had PhysX) if I got it right. So far I had plenty of sudden car jumps because of what looked to be normal wheel force from contact, getting weirdly high. Also had some sudden object jumps, flying far very quickly. All not looking good or real, seems like an unstability. I did increase substeps and decrease interval to get better simulation at high speeds, and I did surprisingly fix that wheels wobbling suspension. I could drive even over 600 km/h in big glass pipe loop and 450 in smaller one. That’s probably the only thing better than in SR with Bullet physics, but I’m still using old version and didn’t try new in years.
    • As of UE 5.3 which I tried, I was not able to turn on Nanite at all, and neither HW ray tracing. And those are UE’s biggest, prominent features. I used Debian 12 and AMD GPU with Vulkan. Saw some post that 5.4 could fix it, maybe.
    • Lumen software reflections. Man, those look laughable. I guess most would use HW ray tracing now or in few years. But I’d rather have my own cubemap rendered and used for other parts too. Instead of looking at Screen Space Reflections (a recent disease) or those blobs (done by Lumen software reflections) when screen space didn’t cover. Plus I’ve never seen car underside reflected properly here. Lastly I tried adding reflection captures and thoses didn’t work. Could be my fault, whatever.
    • Many effects are iterative, updated partly over time, and so they work best when not moving. E.g. volumetric fog lit from car lights, is moving inside car when driving. Reflections also have some noise, changing pixels. Global Illumination with Lumen, also does fluctuate and spread unevenly over time. Sure, it’s new technology and best if it didn’t melt GPUs doing impossible today. But it feels to me like these are just targeted for those indoor furniture designs and static shots, not games.
    • Many things even vehicle parameters need that Compile pressed after changing, then running to test. Really not convenient. The default vehicle simulation is completely nonsense. I guess it could be good for basic arcade games. That’s to be expected. Can’t touch dedicated C++ code for vehicle simulation like VDrift or even RoR with deformation. I found an older UE4 vehicle simulation, whole made with blueprints. Is good to learn from, didn’t feel great to drive though, but I’ve spend not much time with it.
    • Lots of thins are still done from console with typing commands. I guess no need to add them to that pile of unrecognizable settings list yet, probably translated though. But on the up side, there are plenty of options to customize for sure.
    • Crashes. Last but not least. IDK if it’s just because I use Linux, or Vulkan, or AMD, or their drivers. Doesn’t matter, either way I had many UE crashes. Luckily I didn’t loose much, seemed to be at end mostly. Still, not a good sign, not for stable software, not for daily use. Also seems to me like UE is favoring NVidia GPUs or maybe they have better hardware ray tracing, IDK and don’t have time to investigate. Ah and trying to start profilegpu did reset my PC instead.
    • Whenever you change key options it will be building over 5000 shaders again, which takes for me 5 min. And Package project at first takes like 30 min, but later it does much faster even less than 1 min. There are slow downs of like 5-15 sec whenever you save a material etc, there are structures in UE that need to be rebuild and this a slow delay when editing.

    🎛️Blueprints

    I’m kind of in the middle with this topic. Both good and bad.

    Quite a lot of stuff can be done using Blueprints. There are games made just using them.
    But then you’ll be dependent on them, which means no full control over what’s happening, and just doing what others tell you to do their (commercial) way. There is no avoiding blueprints, even with C++ code.
    Another thing is that the list with blocks in blueprints is again huge. Here even a video with main ones. So usually you’ll have to type more to find a block. Even if + or * etc is enough to get simple operations, that’s still just ridiculous for me as a programmer to put a block and connect those lines to it, instead just typing + in code.
    But yes, they’re easier to understand for non programmers. Still, I felt like I didn’t know how to do anything at all, when I was starting with blueprints. So it’s not like those were easier to start, just less to set up (no external IDE, compiler).
    Lastly big, complex games would require a lot of code, which in blueprints means few times more clicking connecting, picking blocks, to me it feels like slow playing with toys instead of developing. And then area is huge, also hard to find stuff, lots of moving around and zooming. Sure there are comments, same as in code. But much more code can fit in text editor. And it doesn’t go both vertical and horizontal (when done right). Doesn’t need zooming. I find code easier to navigate (definitions, references) too. All can be done faster by keyboard.

    There is a cool webiste with lots of blueprints here.
    One good part for blueprints (similar to scripts) is their safety, since they show errors, won’t break, etc. While code can crash, corrupt memory, loop infinitely etc. And could take more time to build and test too.

    ☑️ Good parts

    At least at start, because I seem to end them with a view that’s not good.

    • A lot of stuff working already. But as the saying goes: if something is good for everything it’s also good for nothing (i.e. not great for anything particular). Also if you wanted a change in their sources then it’s a huge amount of it to even grasp (like 50 GB total). And more games using UE will mean more will look the same due to its technology.
    • Plenty of (free) Plugins. Even fancy things like Niagara (3D smoke and fluids simulation, rather not for my/current hardware). But Water is still Experimental (yet essential), and I had some bugs with it (underwater fog was bad at times, even white flashes, then after publish it was at random level above sometimes). Very many plugins are also in Beta and version 0.1. Seems like it’s still too early. IDK maybe UE5 is still too young. I’m obviously only considering free plugins.
    • Useful modelling tools included. E.g. video. Can quickly edit and draft a scene with basic models, already inside UE. For me not needed, as we already have our assets, and tracks made.
    • Many possibilites to generate and place stuff (meshes, vegetation etc) with PCG. Still, those are rather new UE features. Which I’d expect much earlier. E.g. someone using UE4 didn’t have them, years ago. And frankly, in Stunt Rally we had automatic vegetation placing and road generation with LODs since the beginning in 2010.
    • Can move camera with W,S,A,D and Q,E, that’s cool, even bookmark places. But I didn’t find a way to change the speed by keys, and sliders don’t allow any values just predefined, IDK.
    • Plenty of debugging view modes and visualizations. Well the rendering engine is very complicated and “heavy” (high HW requirements) so these will be needed to optimize, probably even if you don’t want to. A very good (but older UE4) video series pipeline bottlenecks, passes.
    • Seems like Visual Studio is again default for C++ but at least VS Code is supported. So my setup with clang and VSCodium won’t work. And OgreNext supports clang officially. UE C++ is also in its own style. Quite old, not even similar to new C++ versions. All variables used and methods use big letters. Video here. Yes it’s a matter of preference (or getting used to) but yeah I dislike this too.
    • Many resources to learn from. Still those are commercials for Unreal and their addons etc but if you filter this out and ignore, then there can be plenty of useful, or universal information to learn in general.
    • UE is definitely huge and complex. With high popularity and big community it’s easy to find solutions to problems. But that doesn’t mean less problems. Actually I found many topics on forum which didn’t solve anything and seemed like unnecessary distraction, like from people not knowing English not only UE. Surely it was easy to find out why I got gray models after Packaging, but why on Earth weren’t shared wrap samplers the default, causing this issue. I think there is a lot of detail to be known to get UE working for any project.

    ⏳Summary

    Well definitely you can learn a lot, not only from using UE in practice, but also from that big number of videos either in their playlist, or lots of other videos from creators around UE. There is also a decent amount of documentation. This can help when starting or using UE, but also for getting information on various subjects around rendering or games etc (just at a smaller fraction).

    So it was a cool experience, completely opposite to mine. I mean using an advanced rendering only engine, built from C++ sources. Not just installed, and already with most needed tools. There is a gigantic gap or difference between those. And not only in software size and thus difficulty, but also in the community. It’s a complete opposite too. In UE (or Unity, Godot etc) you can simply even put your question in youtube and find a video (or few) with answer. When I was searching for UE vehicle tutorials there were even few playlists with that.

    Still, it’s not reasonable to change rendering or game engine far in production. Only possible at start. And SR is and already was far in production, having my own coded features, even when those engines weren’t available, that popular or so feature full. So clearly just because of that I won’t really be able to change engine. And neither would I have patience to spend 2 years or so, right after I’ve spend over 1 year to move “just” from Ogre to OgreNext.

    UE is big, and very commercial, so Windows, NVidia, Visual Studio are default, if not only option here for all things to work. So definitely not for me as a Linux only developer. I think they also use some telemetry, I’m not sure, but I saw urls, sent to their website from UE, as warnings in log, when I didn’t have internet.

    Lastly there are plenty open source engines, e.g. listed here, or new list here, also tools here, and a big collection of engine related links here with lots of libraries and sources.

  • 2022-24 Terrain Demo ⛰️

    2022-24 Terrain Demo ⛰️

    ⏱️Overview

    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.

    📷Gallery

    Screenshots here.

    ▶️Videos

    Are here: new, old.

    📂Sources

    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.

  • 2020-22 K.C.4 Controller ⌨️

    2020-22 K.C.4 Controller ⌨️

    ⏱️Overview

    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).

    📷Gallery

    Album with pictures here.

    ▶️Videos

    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:

    NameAssembly yearOriginal keyboardKeys actuation
    [gram force]
    Notes
    CK3 > CK6 > CK92016 > 2018 > 2020A4 Tech KX-10023 gCheaper, bit wobbly, but more keys
    CK2 > CK4 > CK72005 > 2016 > 2018Logitech Ultra X Flat33 gStiff foil, old, extra keys
    CK5, CK5b2015, 2020A4 Tech KV-300H9-18 gThe lightest foil
    CK12004Logitech Ultra X Flat25 gFirst, old, had extra keys,
    now only for testing, 1 row dead 💀
  • 2018-19 K.C. Controller ⌨️

    2018-19 K.C. Controller ⌨️

    ⏱️Overview

    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.

    📷Gallery

    Album with pictures here.

    📂Sources

    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:

    NameAssembly yearOriginal keyboardKeys actuation
    [gram force]
    Notes
    CK3 > CK6 > CK92016 > 2018 > 2020A4 Tech KX-10023 gCheaper, bit wobbly, but more keys
    CK2 > CK4 > CK72005 > 2016 > 2018Logitech Ultra X Flat33 gStiff foil, old, extra keys
    CK5, CK5b2015, 2020A4 Tech KV-300H9-18 gThe lightest foil
    CK12004Logitech Ultra X Flat25 gFirst, old, had extra keys,
    now only for testing, 1 row dead 💀
  • 2008-09 SPH with CUDA 🌊

    2008-09 SPH with CUDA 🌊

    ⏱️Overview

    The program from my master’s thesis from 2009, implementing Smoothed Particle Hydrodynamics using CUDA and proving 5 times faster simulation of small scale fluids on GPU vs CPU.
    Nowadays I would rather use OpenCL.

    The program is very fun to play with and has a vast number of 119 predefined scenes.

    For 56k particles it allows about 2 to 3 times slower than realtime simulation, due to small time step requirement of SPH.

    📂Sources

    Code is on github along with Windows Release 1.0.

    📊Features

    Bold marked features have own tab groups, with sliders for adjusting parameters.

    • Camera with adjustable near distance cut
    • Visual lighting parameters for rendering particles
    • Collider moveable by mouse
    • Emitters and accelerators for flow or fountains
    • Rotors with various shape allowing propellers
    • Two types of Rotational Pumps (like those for PC water cooling or aquariums)
    • Dye allowing flow tracing, with adjustable fading and shape
    • Bounds with Heightmap, sinus modulated, possibly with holes
    • Moving border for shore waves generation
    • Simulation with parameters:
      viscosity, stiffness, time step, gravity
      and vertical acceleration for flow with cyclic borders.

    Some scenes use high stiffness which requires slower time (10x), but acting closer to incompressible liquids. Tested on NVidia GeForce GTX 560 Ti.

  • 2007 Physics 🎳

    2007 Physics 🎳

    ⏱️Overview

    These are various demo projects done at work, using PhysX a realtime physics simulation engine. More or less the same features can be achieved using Bullet, is open source and IMO better. I did everything it offered then, e.g. rigid body, joints, cloth, fluid and car (tires) simulation.

    📜History

    I also implemented rag doll (for bodies) and water buoyancy areas. I had a demo with rag doll in water.

    The job was very underpaid (also my first), but educational. Also good experience for my next job, since it used PhysX too.

    In the next one I implemented sailboat dynamics and water buoyancy for objects, way simpler (for my taste), but at least fast. The algorithm was for a height based water and just used 2 points on each shape type to compute forces.

    ⏳Summary

    So I learned and developed many things for game physics at the time. Definitely not all, e.g. no simulation or destruction/fracture, which got me interested. But I’d say I was a game physics programmer for few years.

    The car simulation was very basic, I continued later on my own with car games.

  • 2006 Terrain, Water 🌅

    2006 Terrain, Water 🌅

    ⏱️Overview

    This is a collection of programs written in C++ and using Direct3D9. Only the first one left (with green terrain) was mostly mine. It was also a project on college, for subject: 3D Graphics (I think). I did way above requirements as nobody even knew shaders.

    📷Gallery

    Link to more screenshots.

    📜History

    The first small terrain had a shader for blending (mixing) terrain textures together smoothly. Already found somewhere on internet. This I knew is needed for good looking terrain for start.

    After achieving just a small terrain and a cloth looking, pseudo water I started searching on internet for open source examples (it was likely the first time for me). I managed to build all of them and customize the demo applications. I didn’t put anything together as a game yet.

    The water in middle was great but very demanding for CPU, which was computing the animated noise and its normals. This is done nowadays on GPU only. Still, it had the best look IMO for years.

    White terrain with water on left, had a great animated noise but was always flat. Originally it also featured reflection and refraction. This always flat water, was still good and we had a similar one in our game years later.

    On right there is a terrain with level of detail (LOD) Geomorphing (also described here) if I remember it was CPU generated though, but had 5 levels. That was a great and complicated implementation.

    The car screenshot was someone’s 3D model, with a 2D driving code I found. I made it 3D, but only on flat ground.

    ➡️Conclusions

    Then I started thinking and realized, I don’t want to write all 3D equations, surely not a physics system. This is when I got interested in available physics engines.
    Today I would definitely recommend bullet for collision detection and simulation.

    Next, I had the same thought for rendering. Writing everything using calls to Direct3D was tedious and not very practical.
    By using a 3D engine, all becomes much easier and one can achieve much more with it. But I knew a guy at college, who liked the first approach, read books for it, and wrote his own engine.
    Later I found OGRE 3D and started learning it.

  • 2006 Shader effects 💫

    2006 Shader effects 💫

    ⏱️Overview

    This is a result of me learning bump shaders with also implemented reflection and refraction (just from cube skybox).
    There wasn’t really a goal here, just to learn and show what could be achieved with my GPU (ATI Radeon 9800 I think) at the time.

    📷Gallery

    Link to more screenshots.

    🔍Implementation

    My code was using WinAPI for window creation and messages. Then Direct3D9 calls for rendering and HLSL 2.0 for vertex and pixel shaders. Also D3DX for anything else like 3D matrix and vector operations, compiling shaders, and loading 3D models (meshes) from X files. Lastly a sprite font, for screen texts (with parameters to adjust by keys) using my bitmap fonts.

    To get mouse and keyboard events I was using DirectInput. I made a camera system to move around the scene, rotate and zoom. There was also 1 point light here.
    I wrote a Timer (based on precise QueryPerformanceCounter) for checking intervals and computing current frame rate (Fps).

    I think I made most of the basic models. I would use Blender for this now. The skull model and all textures were gathered from other demos and games.

    ⏳Conclusions

    Professional made textures made the demos look quite good, already with simple 3D objects.
    But those were just demos. In a bad looking, low level written code.

    I continued using just C++ and Direct3D9 for a while in next project’s forks with terrain and water. And after that moved to using OGRE 3D engine.
    All that was too tied to DirectX and would need major rewrites every time I wanted to use new DirectX interface. Another good reason for using an engine, it can have different rendering systems also OpenGL based.

    Still, this experience was good learning for future, as I was developing shaders in Stunt Rally too, years later.

  • 2005-06 Crystal Font 🔤

    2005-06 Crystal Font 🔤

    ⏱️Overview

    This is one of my oldest Windows programs in C++.
    It can generate colorized bitmap fonts from true type fonts with glow effect.

    Done on college as hobby around 2005-2006.
    I used bitmap fonts from it in most of my programs, until about 2010. Additionally it made the text for my logo, and lastly the speed and gear digits in our game.

    📜History

    I had a small font tool without GUI, earlier when I was programming in Delphi. This one evolved to be a full featured program with medium size code.

    I presented the program at college, during scientific circles session, for 15 minutes. The presentation was also a good experience to have.

    It was a nice, useful program for me. Probably difficult to use for others due to only keyboard navigation and value changing. It had a help screen with shortcuts though.

    📂Sources

    Later I’ve uploaded it to Source Forge and thus it became my first FOSS program. Then I moved to Google Code and when it shut down, moved to GitHub.

    Available here.

    There were several programs done called bitmap font creator, maker or editor. It was (or still is) a popular thing to do. Both using bitmap fonts and making a program for it.

    📊Features

    Among other features it allowed quick loading and saving project files and coloring schemes. Also browsing them in its own lists with previews. One could easily pick a scheme for font color and quickly match another for glow.

    Glow was computed on CPU and thus rather slow, especially for big font sizes and large textures. I didn’t develop it further after realizing that all this could probably be done with a GPU shader in real time, even with animations, at least for small to medium fonts.