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.

Devlog 10 - We are in the double digits 🎊

UI Redesign Progress

I am slowly redesigning the app to look like the design I made. I started with the sidebar and then the top control panel. All that went well.

The Graphs… 😅

But then I got to the Graphs. *Oh, the graphs…
*I wanted to redo the backend for them because the
multiple-thread approach was just straight up stupid. It was a pain to develop and would be a pain to maintain. So, in my infinite wisdom, I have gone for just a simple async function. That means that right now the frontend is requesting each data point instead of subscribing to a stream.
After that, I needed to revise the frontend graph component itself. At first I just wanted to make a non-messy implementation of the old version. However, it turned out that the HTML <canvas> element is really slow.
And I mean realllllllllly slow.
So after I wasted like 2 hours trying to optimize the design with no success, I rage quit and went to watch a movie.

WebGL to the Rescue

But I don’t give up that easily.
After the movie, I reimplemented the graph view with WebGL through Pixi.js, which wasn’t even that hard like I expected and overall had much better performance.
Well… at least after I fixed one very stupid bug.

The Bug That Ate 10 GB of RAM

I had forgotten everything from the first GraphView.tsx implementation, so I was just mindlessly copying over the code and renaming the variables to what I thought they meant when I first made it.
Then I got to the part which draws the lap (aka the big loop over all the points-up to 10,000 points at a time).
There was an error on one of the variables. It was the length of some array. I just renamed it to the main array length because… *what other thing would it be, right?
*Well…It was the length of the values array, which was always 1 or 2.So I accidentally turned 1 × 10,000 iterations into 10,000^2 iterations.
Somehow the app still wasn’t lagging that much.
It just took like 10 GB of RAM.

The Result

Thankfully, the new WebGL + Pixi.js approach is way more efficient, so after fixing that bug the graph rendering performs much better. It still isn’t perfect on the UI side of things but I am getting there!

Devlog 9 - THE REDESIGN

For the past few days I’ve been working on a new design for the app. I am not the best designer and to be real I didn’t enjoy it :D. Designing is just too illogical for me. There’s not really much more to say about this. Enjoy the design:

Devlog 8

Do you guys remember how I said that I will take a break ? Yeah… That didn’t happen. Instead I have made a plan for myself on how I am gonna continue in the tool’s development.

Da plan

The plan Is pretty simple: Design the app in Figma, then build it! I have also made a list of features that will be added. You can find the plan on Github. You can also suggest features if you’re interested!

…oh and before making the plan I have implemented a pretty cool logging feature. Basically it records the currently selected driver and saves all his data to a file along with the lap time and date. It does this only for laps that the game considers valid (aka gives a lap time to.)

DevLog 7

This will be just a quick update on how things are looking right now, what’s happening, and the overall state of the project.

Good news

The rewrite is complete

The sole UI library is now ShadCN.
There have also been some minor bugfixes and ux improvements. The main being that the app is now working on lower resolutions.
We’ve got a readme. It’s basic, but its there. Also I have added installation instructions and released the 1st alpha version. You can find it in the releases! Both windows and linux packages are there!

Bad news

I will take a break for the next few days. I will be working on a smaller project for android and I hope that by the time I return I will be full of energy and ideas!

What’s next

I will continue working on the graph view. Mainly saving and loading reference laps, and overall better UI and UX.

DevLog 6 - Windows support and the first rewrite!

Windows support

There’s not really much to say about this. You just get a handle on the game’s memory. This was vibecoded but it’s below 100 lines of windows specific code, so I’m gonna allow it. (It was just the 2 function that handle updating the telemetry and the rest is the same.)

Rewrite

After adding windows support, and sending it to a friend to test, I have discovered a massive problem. The app just didn’t work on a lower resolution. Since I have a QHD monitor, I didn’t notice it.
Also when I started writing the app, I did it in pure React without any UI libraries, then I started to use Antd and then MUI and it became a mess.
So I have done some research and decided to rewrite the app using ShadcnUI. I did this because Shadcn has one massive advantage - the code that you use is in your codebase. This means that you can modify the components however you want. It is also one of the more popular ones out there. For icons, I will be using Tabular, because they have a lot of them, and I like their look.

DevLog 5 - Introducing the Layouts feature!

So for the past few days I was implementing a layouts feature for the Graphs view in my app.

Features:

• Adding layouts
• Removing layouts
• Managing layouts
  • change what graphs they display
  • change the properties of those graphs aka their number of gridlines, color and type
  • How many graphs there are and what sizes they have

You can do all of that in the Edit Mode. This mode is accessible via the layout selection dropdown. In edit mode you have options to change the graphs as said, remove the layout you’re editing, to save it as a new one or to save it (basically override the last one). All of this is persistent between sessions.

Note that the UI in the screenshots is probably gonna be changed in the future and is just a development placeholder :)

DevLog 4
Today I have started implementing the layouts feature.
There’s not much to really say. The graphs can be vertically adjusted in size, their color and type can be changed and there is a whole new edit mode for that. And that’s what I did for 5h today… (I really hate frontend :D) The design of the whole thing is unfinished but hey, it works. Even though some features (mainly saving and loading layouts) are missing its turning out great. I will continue developing this feature for the time being.

DevLog 3
This one will be more about the organization of the project.

New folder structure

I have split up the src directory into a few different subdirectories mainly pages directory which is further split up into directories for each page and a components directory for reusable components like the sidebar.

Logging

Furthermore I have implemented logging on the backend. (It’s also callable from the frontend but that’s not that convenient at least in case of debugging so I won’t be using it as much.)

The top bar

Next I have started implementing a top bar for the telemetry view. On there will be some important controls and information regarding that view.

Just note that in the screenshot the game is not open therefore the driver dropdown isn’t populated with any text. This will probably change in the future. And the layout dropdown is there just for the looks for now ;)

DevLog 2

Today i have fixed a bug where threads would spawn infinitely. I’ve been at it for 3h… Yeah it was kinda pain.

So I basically have this architecture, where my backend spawns a new thread for each graph ( to provide information more responsibly. ) However whenever the graph element unloaded, it didn’t unsubscribe from that thread. A simple fix, just unsubscribe it, right ? Yup basically. However my lack of expertise in this kind of stuff led me on a wild goose chase. After I realized that what I am doing is stupid, it was just a simple hook that the spawn function returned, when spawning the new thread. Well we all make mistakes :D

DevLog 1 — An Introduction to My Project

Hi! I’m Karlito, and this is my first devlog. I’d like to use this devlog to introduce my project, explain its current state, and share my plans for the future.

So, what actually is LMU Telemetry?

The TL;DR is that it’s a telemetry tool for Le Mans Ultimate. However, many people don’t know what that means, so I’ll explain it here.

What is Le Mans Ultimate?

In short, Le Mans Ultimate is a racing simulator. Unlike traditional racing games, it doesn’t simply say “the car accelerates when you press W.” Instead, it simulates the engine, tires, driveshafts, brakes, track grip, and many other factors to provide a realistic driving experience.

What is telemetry?

Telemetry is a way for simulators to output simulation data, such as speed, position, engine temperature, and much more. At a lower level, it’s essentially a chunk of memory containing numbers that are constantly updated with current information.

What LMU Telemetry actually does

LMU Telemetry aims to visualize these data points in a way that’s easy to understand and can help users improve their driving. It does this in several ways. For example, one feature draws real-time graphs of various metrics such as speed or delta time compared to your best lap.

The current state of development

The app is currently little more than a glorified demo. It has some rough UI elements and only plots graphs for a hardcoded car (index 0). While this works in private lobbies, where you’re always the first car, the system fails in most other situations.

In short, the app isn’t very useful yet, but it’s a start.

Main goals

• Live telemetry view
  • Real-time graphs
• Map view
  • A view showing the track layout and the line you drove
• Sharing features
  • Exporting laps and comparing them with laps driven by other users

Requirements

• The app must be performant
  • Running LMU can already be demanding on some systems, so the app shouldn’t use more resources than necessary
• Linux support
• A reactive and polished UI

Future plans

• Windows support
  • Depending on how difficult this turns out to be, it may be implemented sooner
• Strategy mode
  • Useful for endurance and team events, allowing you to monitor the tire and fuel status of other drivers

So, what now?

Right now, I’ll focus on getting the app to its MVP state. This means refining the UI, fixing bugs, and, most importantly, making the app genuinely useful.

Well, that was quite a long one, wasn’t it?

Thank you for reading all the way to the end, and have a wonderful rest of your day!