Category: Forks

Other project modified by me

  • 2024 Rigs of Rods tracks

    2024 Rigs of Rods tracks

    ⏱️Overview

    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.

    📂Media

    Downloads
    for RoR tracks are in this topic. Also require assets from here.

    📷Screenshots
    gallery from many tracks start here on RoR forum topic. Also older WIP here.

    ▶️Video here
    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.

  • 2019 DoubleCmd Fork 📂

    2019 DoubleCmd Fork 📂

    ⏱️Overview

    This is my modified version (a fork) of Double Commander (DC), a two panel file manager. I first forked it in 2017 and in 2019 I finally moved to using it daily instead of Total Commander. I will describe few aspects here.

    ℹ️How to start with DC

    Here is a short paragraph upfront, for those who didn’t use a commander or are new to DC and want to start using it (or give it a try). I recommend the main website (for download and support) and the documentation (help) about how to use its functions.

    Double Commander

    DC is cross platform, so it runs on Windows and GNU/Linux. It is inspired by TC. There are of course many other file managers, (some even in text mode like MC), but I think DC is perfect for me and I highly recommend it.

    The best features of DC though (for me), are being Open Source (FOSS, this gives Freedom) and still developed. What it means (especially for me) is that I can learn how it works and can change it myself. Or even add new features, including those that only I will use. And I can contribute to the project.

    📜My History

    I started using a file manager as a kid, already on my first PC which had DOS. It was Norton Commander (NC, in text mode). I quickly got to using it daily, as my main program to do all file and directory operations. I didn’t even know how to do them using DOS commands for a while. Well I barely started learning English and wasn’t able to read any documentation too (it wasn’t needed BTW).

    When I was moving to Windows 98 (around 1999), I naturally wanted a similar program. I didn’t like Windows Explorer at all or even windows in general (I was still sometimes going back to DOS). Fortunately there was a similar program, at the time simply called Windows Commander (WC ?). It was later renamed to Total Commander (TC). Using NC in Windows was possible, but not always, since DOS had short file names and Windows has longer.

    WC was better than NC, my favorite feature probably being that it could color file names by extension. I think it’s when I started adding my colors for file extensions I got to work with.

    Naturally, when I started using Kubuntu and later Debian, I wanted something like TC.

    ⏳Before I started

    I actually reported a couple of bugs that affected me the most and honestly prevented me from using DC. I was also too inexperienced to even try fixing them myself. Lastly those weren’t easy things to fix.

    These were:

    • Very slow File Filters. It took 4 seconds of delay to view 24000 files in a directory with my settings having 123 file filters. Directories over 1000 files were already entered with noticeable delay. And yes, my file extensions list grew and became something that I enjoy since years. Surely not something that I would throw away and just not use it.
    • Freeze on entering unreachable network paths. It happened often at work (where I had to use DC not TC) and also for more people. Application froze for nearly a minute. So quite an inconvenience to kill the process every time someone accidentally tries an unreachable path or a tab with it.
    • Compare by Contents not Implemented from Search result and archives. A simpler bug for a useful feature.

    After a few months the first issue was fixed. So I started making my own program to deal with my file extensions list for both DC and TC. I had a lot of them 96 in 2017 and 239 in 2019, this is just the count of unique colors (file filters), though I split some for readability (e.g. for Stunt Rally track sceneries).

    The program has its own page and is called Crystal Color Center. I’m sharing it with my list included. It allows an managing the list on an even higher level, with features like: groups, search, quicker editing (with R,G,B sliders) and of course import / export for both DC and TC. Thanks to it, moving my list from TC to DC was easy and any changes to it is fast and conveniently done in my program.

    The second bug was fixed after a year (still, I can’t complain since I didn’t do it earlier). But earlier it became not that needed anymore for me.

    After that it was probably the time, when I realized I should fix the rest of my issues with DC. I mean just missing things from TC that I got so used to. It also turned to a nice learning experience and woken up old memories from Pascal.

    ✍️How I started

    Well the start is the hardest part of any software (program or game) or even any project in general. To start, the page Building from source is crucial. And I believe it’s probably the most important page for any FOSS project. Of course beside a good documentation for users. Fortunately the instruction is not long or difficult.

    Sources are surely different, because DC is written in FreePascal. Lucky for me, I knew Pascal since DOS and later Delphi in Windows. So I had some start and the rest is nicely explained on internet and in language documentation and wiki. But basically I prefer to just search on internet for particular problem. It doesn’t matter where I land (doc, wiki, forum, stackoverflow, etc.) to read the solution or hints.

    At first I was building just from command line. After installing packages for Lazarus IDE (a bit more trouble) I could develop in it. Naturally I created my own color theme for Lazarus IDE as a result. And I also saw that weird build “Internal error 200611031″ plenty of times (well count – 1 too many).

    FreePascal

    The DC code is quite big and it surely requires time to get a hang of it. Learning FreePascal adds even more time. But it is a very nice (almost funny) language which also reminded me of my earliest years of programming (at college I moved to C++ and later also C#).

    Pascal language doesn’t use so many symbols, making other languages look more like a forest. Pascal code looks more like a book. Not a phone book, a novel. An English book where people write what should happen. Assuming that comments are written in English too, which I recommend always.

    Well let’s have an example, I have cut and pasted few very readable lines here:

    uses
      Forms, Controls, Dialogs, Buttons, Menus, Classes;
    
    procedure LoadSettings;
    function GetOptionsForm: TfrmOptions;
    function GetAName: String; virtual; abstract;
    destructor Destroy; override;
    
    const
      allowed : set of char = [ '-', '.', '_', '~' ];
    
    var
      I: Char;
    begin
      for I := #0 to #255 do
      begin
        case I of
          '_', 'a'..'z', 'A'..'Z', '0'..'9': Identifiers[I] := True;
        else
    
    implementation
    
    if not Assigned(Operation) then Exit;
    Operation.Execute;
    
    with Operation as TMultiArchiveCopyInOperation do
      begin
      if cbEncrypt.Checked then
        repeat
          ..
        until sPassword = sPasswordTmp;
    
    finally
      Free;

    ⚖️Pascal vs C++, quick rants

    Well I can’t say I’m finally free yet ?, but surely many things from Pascal are great and make it very nice to read. E.g. that uses statement at start, compared to #include each in own line in C++. Or the with do statement that shortens a whole block below.

    C++ is a horribly unreadable at start. And just to mention, some terrible mistakes made by just one symbol, like if (i = 0), instead of ==, that compiles fine. But I did like { } brackets for blocks, instead of begin and end, how many times did I spell them wrong.

    I also remember my favorite thing from Turbo Pascal: F9 key to build project, if there is an error it jumps to it in code. Far too many times in Visual Studio I pressed: F1 to show error list, Enter to go to error and Shift-Esc to close that bloody thing. I can’t even ? (and those are my own shortcuts, just Esc won’t work).

    It is much better with C# where it compiles in background and underlines bad expressions in code already.

    One great thing in Lazarus IDE is that it makes tabs for each search you do. Why on earth can’t VS do it??

    I could go on. But the point is, it was really nice (for a change) to code in a completely different language. I think I’d put Pascal after C++ and before C#. Okay then, that’s it from off topic.


    📊My version

    Now we finally arrive at the main and most interesting part (at least for me).

    After I was able to use Lazarus IDE and felt good with Pascal (again), I wrote new features and customized DC to my liking. I also made source patches for some features on DC BugTracker.

    📂Sources

    Full list of my changes (in commits) can be browsed here (or locally after cloning with Git).

    Here is what I changed and why:

    • Undo Close Tab
      I simply can’t imagine having dynamic tabs anywhere without this. We’ll see if it gets into final DC release, and when.
    • Multi Rename tool
      More compact look and new functions listed here. Probably the biggest update.
      I use this tool a lot at home, e.g. dealing with thousands of screenshots, deleting later half or one third of them, re-enumerating them with this tool and doing it again.
    • Status bar
      New look, visible on screenshot above.
      I really like to have a different status bar (text and color) for when anything is selected.
      I once had selected files, not visible at cursor, forgot them, wanted to delete a file at cursor and deleted them all.
    • Size colors
      Next, why shouldn’t I have different colors for different sizes (K, M, G etc)?
      Sure for some it’d be too much color. But I’m using the same idea in my audio player (cAmp), coloring track times and I find it informative.
    • Gradient for cursor (blue) and selection (orange).
      Also visible on screenshot above. I think it’s nice, more futuristic.
    • Follow links to destination.
      With Ctrl – (Left,Right or Up), quite a useful thing.
      I have few dirs with just such links (.lnk files) and use them as my starting point e.g. when developing one of my projects.
      And BTW a quick feature to use Ctrl-Shift-S on cursor to make a link to it, without asking.
    • Find Files results, Color by file types.
      Another useful extension. Seems natural for me, to have any list of files use coloring by file type (extensions) especially when I have so many in my list.
    • Some smaller things.
      Not very important, but definitely nice to have and a cool exercise to find it in code.

    Another thing of mine is file and directory rating. I use it constantly since years too. This is visible on screenshot above as symbols ` ^ ~ + after name. It makes it easy to spot more interesting files/dirs and makes them change color (usually intensity). It is also an internal feature of my player to apply the symbols to filenames.

    ⚙️Contributing (in general)

    There are a few different change types to software, that anyone can report, contribute, or have on own fork.

    • Bug or issue reports.
      This is relatively easy to do as user. And is surely a good thing to receive as a developer. With more features in project and more systems where it can run, it is difficult to catch bugs. I didn’t like those reports as a Stunt Rally developer, but without them it would be a more buggy game.
      But still, there is probably nothing worse than a post “help, it doesn’t work”, without any (not to mention all) data required like version, OS, steps, etc. In that case it’s better not to post.
      There is a general guide for “how to report a bug” and some project have specific ones.
    • Bug fixes.
      Like those above, but better. They requires programming skills though. It’s when you fix a bug yourself and submit it (to developers).
      In Git that would be a pull request (from your fork, name is surely misleading). It is less trouble to merge and test, also more convenient to discuss (on website Codeberg, GitLab, Github, Bitbucket, etc.). But sometimes a patch is enough.
    • Ideas.
      Well that’s just the worst IMO. Everyone has them, just having is not much worth. Discussing them could mean wasted time on development. And developers have usually their own ideas and vision of project. Having more doesn’t help. But, I guess, it could be some help for starting projects, with not set vision yet.
    • New features, implemented.
      That is way better than just having ideas. Being able to turn them into reality. One can submit those to developers. But there is a catch. Not all will be attractive to put into project. Having too many features makes a project more difficult to test and more bugs are possible. And could make it more cluttered in GUI or Options (wasn’t an issue in my projects).
    • Custom own features.
      This is why I have so many forks. I do have plenty of ideas, I implemented them and I’m pretty sure nobody (from the developers) would care or want to add them (reasons above).
      Additionally, since I have a lot of preferences, it is natural to keep them in my own forks. This way I can keep up to date with upstream (main) project versions and have my stuff too. Priority for me is to keep my stuff.
      But merging upstream versions is needed too (once a while) even if it takes time. If not done, it would at some point accumulate too much, making upstream update too time consuming. Sometimes in that case, it could be possible to apply (merge) own changes (only if not too many) to a fresh upstream version.

    ⏳Conclusions

    My move to DC was surely long and took many steps. But I’m glad to use FOSS, not just as an alternative to commercial, but to prove that it’s simply the only logical way for me. It was obvious already earlier, when I created my own audio player (I use it everyday).

    If you’d ask me why I didn’t yet move to GNU/Linux (from that Windows crap) it is because of all those steps needed. DC was one of them. Rewriting my audio player for GNU/Linux is next. There are few other programs I customized and got used to (Video player, Image browser, etc.) but those two (DC and my cAmp) are crucial.

    I think I also showed some aspects of FOSS and the great things it brings. In particular, opportunities to: learn, express creativity and adjust to own needs.

  • 2016 Keyboards CK3,4 ⌨️

    2016 Keyboards CK3,4 ⌨️

    ⏱️Overview

    The newer two of my heavily modified keyboards. This time having Teensy 3.1 (or 3.2) as microcontroller with a tiny 1″ monochrome OLED display. Firmware was based on Kiibohd, it was a fork with my extensions. I added display support (with a library), menu for editing e.g. macros/sequences, few demos and a game.
    I did improve them further in my newer firmware, with bigger display.

    🛠️Modifications

    The first operation I did, was cutting off most of all rubber domes. This makes the keys much softer to press, so needs less effort or fatigue. The result is minimized pressing (actuation) force and distance. Simply more pleasant and comfortable. Also healthier, since the risk of keyboard injuries decreases. I already did that earlier on my two oldest keyboards in 2005 and 2006.

    ✍️Motivation

    Originally most keyboards need about 50 gram force needed to press keys, and probably 4 mm distance. After cutting, the distance is about 1-2mm, the force is at 23 gram for CK3 (top), 33g for CK4 (bottom) and 9-18g for CK5. This can also be varied per key (more detail can be seen on pictures (galleries below), but ultimately the lowest value depends on keyboard’s foil thickness.

    ⌨️Additional keys

    For CK4 there are also few small extra keys. Which were present already in my earliest keyboards CK1 and CK2. Those are glued on top and are made from lightest 0,5N switches available. The row above numpad is used for my audio player control. Rest is custom. This part is optional and I didn’t do it for CK3. The disadvantage is the difference in pressing those switches and much lighter normal keyboard keys. They are smaller so you can fit more, but are less convenient to press. Lastly, regular keys can be used to switch layers instead.

    ⚙️Microcontroller (MCU)

    The second step was replacing the keyboard controller board, with my own. The hardware is composed of Teensy 3.1 (or 3.2) with a tiny 1 inch OLED display (SSD1306, monochrome, 128×64) and a bunch of wires to connect to the original keyboard’s matrix.

    The reason for this was to take advantage of already made open source Kiibohd controller allowing any imaginable keys assigned and layers. Also possible are macros, key combinations and even mouse buttons and movement simulation. But changing any of this required rebuilding controller software and uploading to controller, through already present USB.

    It was a bit simpler to start at the time, instead of writing my own later.

    📊Features

    After getting it to work, I implemented my own menu where you can edit sequences, stored in memory (remembered after power off). The sequences are very useful for not typing passwords or simply binding some useful macro combinations or commands dynamically. Which needed a display and menu for entering.

    Once I’ve done the useful stuff, I got carried away and implemented several demos on display and even a falling blocks game.
    I also wrote about it in this forum post.

    📂Sources

    The code is in my fork here with some more detail.

    📷Galleries

    There are picture galleries below, also from assembly and videos.

    All galleries up to now, from my keyboards are as follows (newest first):

    Most pictures have some description text (explaining what I did there).

    1. CK4 final (18 Apr 2016)
    2. CK4 assembly (Apr 2016)
    3. CK3 final (11 Apr 2016)
    4. CK3 assembly (Apr 2016)
    5. CK3 rubbers cut and glued (Apr 2016)
    6. CK5 / Ultra light press mod 9-18g (2015)

    And the older ones:

    1. CK2 final (2008)
    2. CK1 and 2 making of (2005 and 2006)

    ✅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 💀
  • 2006-07 Stunt Playground fork

    2006-07 Stunt Playground fork

    ⏱️Overview

    Somewhere around 2006 to 2007 I was learning OGRE in practice by forking an existing project. It was Walaber’s Stunt Playground, original video looked quite different. Is on website, but the sources aren’t available anymore (he’s gone fully commercial).

    📜History

    OGRE was very popular at that time, had many plugins, so it was the best choice of engine for me. Its version was 1.2.1 (Dagon) then.

    GUI was made using CEGUI and physics with Newton Dynamics through OgreNewt. Both of which I didn’t continue to use later since their limitations.

    📊Features

    The game had few cars, dynamic objects, an editor for placing and moving them, loading/saving maps, replay and sound systems.

    Tracks were exported just like objects, which posed a big penalty having no level of detail on them. Plus tedious editing in 3D modellers (not in own editor) and lastly not allowing an optimized terrain, grass or trees.

    ✍️Motivation

    Back then it also had open sources, great to learn from and not too big (180kB total). Compiling them was also not too difficult for me at that time. I learned a lot by modifying the game and it was a perfectly fitting experience that moved me forward in the direction I wanted to learn, without too many obstacles.

    ➡️Next

    The static tracks got me into looking for terrain editors next. And I eventually developed my own track editor years later.

    Now, if you know Stunt Rally 😉, you can probably already start spotting something similar. Well the camera system is greatly based on this one. And particles like sparks and dust I developed then are nearly the same.

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