Devlog 29 - The end

So this is the last one, huh.

Here is the full write up on this project as I promised.

Chapter 1 - The beginnings

This project started about 3 months ago. I started experimenting with just getting the data and plotting it. Just for fun as an exercise to learn rust. Then I realized that there actually isn’t a proper working telemetry tool that works on linux. So I did some research… and I decided that I am going to make the app in Dioxus.

Chapter 2 - The Dioxus era

This leads us to the shortest of eras. The Dioxus era. Nothing really happened here and quite frankly I don’t even remember it that much. There aren’t really any git commits because I didn’t have that setup yet. One thing i remember tho is that I couldn’t figure out how to draw the garphs, because Dioxus is based on web technologies but weirdly becuase you are writing HTLM like syntax but in rust. And that was the main reason I decided to switch to Tauri.

Chapter 3 - The Tauri era

At first Tauri was the best framework ever made for me. That is because I already kinda knew react, it was simple to understand and I could really lean into the split frontend and backend architecture. This sadly proved very inefficient for the graph view which needs to render thousands of points each frame. Since it was too much for the basic HTML canvas I have switched to using WebGL with numerous downsampling techniques. This was just a bandaid fix though. I have also ran into bunch of architectural issues with the whole split frontend and backend thing. Accessing the telemetry data proved to be very difficult and inefficient. I remember that I ran each of the graphs on a separate thread. This was so stupid. I don’t even remember how I could’ve come up with such a stupid idea :D. It just led to memory leaks and threads uncontrollably spinning up and not stopping. I am sure that all of that could’ve been easily avoided with simpler architecture but at that point I was at my lowest point of this project, so I didn’t even have the energy to do it. I also had the state of the frontend so fragmented which didn’t help. And the whole retained mode GUI thing just wasn’t well suited for this kind of app. And that is when I decided to do a complete rewrite in pure rust!

Chapter 4 - The sweet EGUI

I didn’t know it at the time, but this was the best idea on what to do with the project. I remember that I was very split between just shipping it half done and finishing it just because of how bad the development experience with Tauri was (sorry Tauri devs, it’s not a you thing, it’s a me thing). It took about 30h to fully rewrite the app with EGUI, which looking back at it isn’t too bad. It felt like ages though. It didn’t help that almost none of the work in this “chapter” did AI. Which at the end of the day is better! Although my style of writing EGUI code was let’s say original… I have just put everything into one file and that grew very fast :D. I had like 5 files that were about 800 lines each. That has since luckily changed. (I have adopted more of a React style file structure.) Anyway at the end of the rewrite I kinda started loving EGUI and that hasn’t stopped since. I continued to develop the Map page in EASY which was pretty easy. But then I needed the track limits data for the map page. This was a bit of a roadblock… First I have tried to extract the data directly from the game, however this was inaccurate and the track width was missing entirely. So then I tried to download an up to date image of the top down view of the track and extract the inside and outside line from it and match it to the in game data. This partially worked better, still not great tho. So there was only one option left. And that was to painfully drive each layout of each track by hand. This took almost 7h of just driving in circles. After that it was smooth and buggy sailing until the ship.

Everyone who read this, have a beautiful day.

Devlog 28

Today is gonna be a big day, because I will ship the project. There is a few things left to do tho. Mainly the readme and the demo video! In my last and next devlog I will also make a write up on the story of the whole project so far.

Besides that I have yesterday refactored the whole codebase so now there aren’t just 5 monolithic files. I went for a more react like approach with the structure being divided into pages and components.

Sadly there isn’t enough time until the ship to touch up on some old UI and UX problems in the edit view of the graphs, neither is there time to add more fields. This will be done in the near future!

Overall I am very happy how the app turned out. But this is not the end of the development this is just the end of the stardance journey!

Devlog 27

For the past few hours I have been polishing the app up.

The main you’ll probably see are the onboarding dialogs. A global one pops up when you first launch the app and then one for each page when you first enter them.

Another change I have done is that I made the ghosts on the map page be based on time and not data point index.

Devlog 26

Hiiiii

For the past few hours I have been working on polishing the app and get it to a shippable state overall. There is still work left to do, but I am getting there.

I have set up a simple packager, and a simple script to use it. It automatically compiles the release version of the app and packages it into a windows installer a Debian .deb package and a pacman package.

I have also (after like 2 hours of struggeling with it) added an Icon for the app. So now it looks nice!There has been a lot of new bugfixes as well and the app has been tested by my friend so it should be somwhat usable, tho the setup UX should be improved upon.

If you wish you can download the app from here: https://github.com/Karlito05/TelemetryLMU/releases/tag/v0.2.3

Well that is all I have for you all today, so have a nice one :)

Devlog 25

I know I have just made a devlog like yesterday but holy s*** the track references work so well. They are practically perfect.

Besides the references I have also implemented the delta time between the 2 cars! That has really tied the page together.

If I can say so myself, we are getting pretty close to the final ship. There is not much needed to implement. The obvious are bugfixes, and some simple onboarding. But really, that’s it!

Everyone who is following or caring about this project can expect a ship in the next week or so. In my final devlog I will also do a writeup on this project as a whole, from the coarse beginnings in Dyoxys, trough Tauri, to the sweet home of EGUI.

There will also be a trailer video and a demo for all the raters :D

Anyway for now you can have this preview of the map page!

Stay tuned!

Devlog 24

HI!
All of the time on this devlog was basically just driving in circles. And I mean that. I have recorded all of the outsides and insides of all tracks in the game to get the data for the map page.
It was very teidius and very boring. Like very very boring. There are 31 tracks in LMU (including each layout) and on every one of them I had to do an out lap, the ouside, another out lap and the inside. So 4laps for each. That is about 15min per layout. Yeah it was a long one. And the recordings aren’t perfect either! I will now have to somehow process them all to get them ready for the ship.

You can watch the timelapses of this process here if you wish.
https://lapse.hackclub.com/timelapse/OQcismBwxbBB
https://lapse.hackclub.com/timelapse/le3Lta0RxcUA
https://lapse.hackclub.com/timelapse/XRf98OimmUk9

Anyway. Have a nice day!

Devlog 23 - More Refactoring

Hi!

In the past few days I have been making some core architectural changes to the project and I would like to explain them now.

Telemetry Provider

I have finally decided on how I am gonna handle telemetry in the long term. It’s a pretty simple concept but the implementation is pretty hard.

I have one object (the TelemetryProvider struct) that is in charge of getting and managing the telemetry. Right now it logs data from all cars and stores the best, last and current laps. If you wish it can save only your laps or laps of everybody. Each lap is a json file about 500kB - 1MB in size and holds all the data that can be displayed in the app. Notably the position ( so you can load that lap directly into the map page ) and the data displayed by the graphs (so you can load it as a reference there as well.)

Pointer to this struct is distributed to pages that need it so they can access it!

The provider has a core logging loop that is running on another thread so the whole UI doesn’t have to redraw each time you log new data. (About 60 times a second.)

State and Settings Providers

Next, I have implemented a StateProvider and an SettingsProvider. These two are basically a drop in replacement of what was stored in the Sidebar and SettingsPage respectively.

Difference between the two is that the StateProvider isn’t stored between app restarts.

Similarly to how the TelemetryProvider works, each of the pages that need these values get a shared pointer (or an Arc in rust) and can access the values.

What’s next

Going further I will keep my focus on the map page. Finish it, and then start polishing the app for the final ship! Wish me luck and have a nice day!

Devlog 22

Hiiiiiiiiiiiii
I have some huge news to tell you. I have just made the MOST complex addition yet. And I love it!

I have completely overhauled the accessing and managing the telemetry! I have designed a thread safe way to have it run on a separate thread and be accessible from *every place in the app. One unified API for everything!
I now store the current lap and the last lap for each of the cars. Tho this takes up a massive 140mb of just floats (in the worst case scenario) I believe its worth the RAM! (Let’s be real, we have saved over 400mb from the tauri implementation so we can now use some of that!)

Next I will continue on further implementing these features around the tool.

Anyway have a nice day people and bye bye.

Some context to that meme: I have a type in my app that is literally Arc<Mutex<[([f64; TelemetryValueType::Max as usize], Option); 104]»

Devlog 21

For the past few days I have been working on a new feature. The map page. It is turning out great, however it has a lot of bugs. These will get fix over the next few days. I promise :)

There have also been changes made to the lap logging system and some other systems as well.

As you can see on the image you select 2 saved laps and can crosscompare the lines you drove. Obviously this is completly useless if you loaded 2 different track like I did here. This will get checked for and prohibited in the future.

Next I will add the underlying lap overlay which I will somehow extract from the game or from somewhere else. I don’t really know yet.

Well that is it for today. Have a great day and bye bye!

Devlog 20

So I have been polishing up the current features a bit and they are far from done. I am starting to question if i will make it to shipping this app one day :D. Anyway I have fixed numerous bugs, added an settings page and implemnted although very crudly a lap logger. But there is still a lot work that needs to be done. I have also added persistancy so the app remembers your choices. I am almost ready to replace the main branch with the fully rusted version, but like I said more work has to be done to go trough with that!

I have probably never shown how the Car info page turned out and IMO it did really well. (The empty space is for inputs. That will be implemented soon!)

Devlog 19

Hello hello!
Today I have some exciting news. The rewrite is complete

That’s right, after about 30 hours of porting this code from tauri into EGUI it is finally finished! So let’s take a look at some stats, shall we ?

|                                             |         Tauri      |           EGUI           |
|----------------------|-------------|--------------- |
| Dev time                          |          80h       |            30h            |
| Lines of code written |            6k         |             3k             |
| Enjoyability                    | suboptimal | above average |

And some perofrmance stuff as well:

|                                             |         Tauri      |           EGUI           |
|----------------------|-------------|--------------- |
| Ram idle                          |    ~700Mb     |         ~150Mb       |
| CPU % idle                      |        ~5%         |          ~5%            |
| FPS under load             |      ~29fps      |       stable 60     |

Some other perks also include that EGUI doesn’t need a browser installed on the system to work.

Overall I think this was a very successful rewrite! I wouldn’t do it again tho

Next I will refactor the code a bit, do a bit off the good ’ol cleanup and then get to work on the map feature.

Devlog 18 - 100h on the project

So it’s been a hundred hours huh ? I also can’t believe it!

I have also just now finished* the graph view which will be newly called Telemetry (page)

Now I will move onto making the car info page previously known as the championship view. I expect this to be very easy!

Devlog 17

Hello guys. Its me again :D

I am continuing to rewrite the UI into egui. I have completed the Graph view’s UI and now I am moving onto implementing it.

One thing I have noticed is just how much more “code efficient” egui is. I understand that I didn’t make the logic behind the code yet but even with that I made the same thing with 3k less lines of code.

Here is how the layout edit mode is looking for now.

Devlog 16

Another 6 hours, another devlog…

Hi people. For the last 2 days I took a bit of a break from the project. I have played Approximately up with the boys and it was so fun. Y’all should try the game. It has a free demo 😉

But we are not here to talk about games, are we…

I am continuing the implementation of the frontend and its coming along nicely. I’ve just noticed one thing, making the UI itself in egui is kinda slow however the state is very easy. Whilst this not being completely ideal i can push trough that.

Since the last devlog, I have finished the implementation of the sidebar, and started working on the telemetry page. I have the graphs sorted and now I am working on the top bar.

It’s having a couple of issues at the moment but nothing hard to fix really. I am hopefully gonna continue tomorrow and have the page finished by the end of the week.

Welp, I guess that’s it for today. Everybody have a beautiful day, and bye bye!

Devlog 15

For the last few days, I have been remaking the UI in EGUI and I am enjoying it so far.

I’ve been working on the graphs in the graph view and also the sidebar. The sidebar is turning out very well and I am also pretty pleased with the graphs.

I have only this for now, so enjoy :D

Devlog 14

I have done some research and decided that moving forward the app will use eGPU as the main GUI library. I have chosen this over the competitors due to a few reasons. The main being that its rendered natively and that its a intermediate mode library. This will make it very easy to work with the graphs and hopefully other stuff too.

I am enjoying working with it so far. There are some concepts that I really like, like that everything that has state is just a simple struct that is initialized somewhere and you do most of the implementation. The widget system is also pretty cool. I was at first worried that I would hate it due to my experiences from TKInter that was forced on me in school :D but its pretty intuitive how they did it.

Going further I will need to think about the architecture of the app a bit to not have it fall apart. Right now I am thinking that one thread will be the main “logger thread” which will gather data from the telemetry and then there will be the UI thread. I think that is what pretty much everyone is doing so it might work . With this approach i am worried that its gonna be a pain, but what isn’t these days…

I don’t really have that much more to say so at least enjoy this screenshot of a pretty much not working app

Fun fact: due to how the lib works there is a bug now that you have to move your cursor on the app for it to log data :DDD

Devlog 13

Okay so I might have found a solution for me not liking react and web technologies but still wanting to finish this project. And I don’t like it…. but it has to be done. But before I tell you what it is you have to understand my problems.

The good

• React in combination with typescript is a very easy thing to understand.
• They are everywhere, the skill of knowing these is very valuable.
• They have a huge ecosystem because they are everywhere.

And I am sure that I have forgotten many other cool and interesting features and perks but I picked them for mainly these 3.

The Bad

• They are slow (in comparison to something like rust)
• They rely too heavily on browsers (I mean it’s basically their runtime)
• You have to be “hacky” to do some things.
• They are not suitable to develop desktop apps

I mean in hindsight those are so obvious but until you are balls deep into some specific project you don’t really think about those. The main problem is that the performance is, for the lack of a better word, sh*t. And normally that isn’t a problem however when you are processing a memory object of about 300kb 60 times per second it adds up fast. Even on my pretty beefy PC (r7 9800x3d and n5070ti) it hardly gets 30 fps. I know this could probably be fixed with “more hacky workarounds” but I am tired of those.

The solution

I am going to REWRITE The project I have spent 70h on already in some rust native GUI framework such as ICED. I have not yet decided which one to chose and I will do that research tomorrow and report back

Literally me RN ⬇️

Devlog 12

This will be more of like a quick update on the championships feature. So what has happened is that I have implemented the feature, and assumed that the data will be there for all players… which there isn’t. The other players show up and everything but the details like tire data, damage data and fuel data just isn’t there. So I am kinda stuck if I should just scrap the feature or recreate it into a personal data panel which would just not be fun I think. Also the damages data is very very limited, so I just don’t know what to do.

Devlog 11
Hello guys. I have some good news and some bad news… Let’s start with the not so good news.

After thinking about it, I have decided, that I don’t really enjoy working on this project. It’s not that the project it self is bad, it’s more about the tech stack I chose… Don’t get me wrong typescript and react are both phenomenal choices and great tools but, I guess the web is just not for me. I realized that I like the lower end of the spectrum better. So I have decided to cut this project short. The map view will not be included in the final ship for the time being and the profile stats also will not be there.

On the bright side, I have started working on the championships page with that nearing its completion. Next I will start to work on the onboarding and settings pages.