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 3 - The last one (most likely)
Hello!
I have added support for triangles. And when you have triangles you can render anything (in theory) in practice anything above like a 1000 triangles is not really able to render :( Sadly it’s very unoptimized… Maybe in the future. But for the time being This will have to do! Anyway, Enjoy this final blender monkey <3

Her name is Suzanne btw :)

Devlog 2 - Long time no see!
This will be the last devlog for this project because the scope is just very small.

Overview

I have added an overview page which sorts your your activities based on how much you time you spent on them. There is nothing much to be said about this, its just a simple database query.

Final polish

In preparation to ship this project I have been polishing the readme and ironing out some bugs. All considered I think it turned out great. It just works.

What I gained from this project ?

I think for how small this project was, I gained quite a lot. I have learned the basics of working with a DB, how server and the client communicate, auth, and some TS quirks. I really enjoyed making this!

For whoever read this far, Thank you for giving a f*** :D and have a beautiful day!

Just a quick update. It turned out that I didn’t use any compiler optimizations when testing the renderer. With them the renderer is even faster. I need to do further testing on how faster, but in the meantime you can enjoy this render that took a whopping 4,500 seconds to render! Each pixel is made of 2500 samples and the ray bounce depth is set to 50.

Devlog 2 - Defocus Blur and Multithreading!!

This will be quite a short one…

Defocus blur

So basically this works by “randomizing” the camera’s origin point. So now, when you want, it could be a small disk on which rays will originate randomly! This “defocuses” (adds a depth of field) effect to the image.

Multithreading

This was a very simple change. I basically just split the work (by scanlines) between multiple threads. Right now you have to hard code it into the code but I promise that I will make a UI for the RayTracer some day. Or at least a CLI. The performance gains are significant. On my CPU (Ryzen 7 9800x3d) was the render almost 5x faster. For how simple this change was, its a massive jump.

I have also linted the code with clang tidy so it follows modern conventions and google’s rules.

Also I’m a bit tired of all the balls already. So next I will look into model loading!

DevLog 1

What a 7h this was :D

UI

I started simple with making the UI. For now the UI is pretty simple. Just a timer, acitivity selection and a add activity input.

Auth

I wanted the app to be usable for more users at once on multiple devices. This is sadly not possible to do with a simple cookie based data storage, so I had to implement an account system with a database. This proved to be pretty difficult as I never did such a thing. The Auth was simple enough, I found a YouTube tutorial for that and all went well. I decided to go for OAuth with GH, as it was pretty simple. I will probably expand this in the future :).

The DB

Oh the db… It was not enjoyable to setup. I went with Prisma to handle the difficult stuff for me, but still, the setup was not smooth. Somehow I think I hit like everything that could go wrong :D But in the end I somehow set it up. Using the db itself for storing and retrieving data is really good and intuitive. So that’s nice.

Next Steps

Next I plan to refine the UI (right now you have to refresh every time you add/remove/change active activity), add some profile page, add login page and add some overview for the tracked activities!