Hi, glad you got it working! Did you simply delete all files related to the app? I believe that as long as you download version 0.2.1, and follow along the above video, everything should be working (I just checked again on an old Windows PC and it works fine). Feel free to tell me if you have any other issue.
Did you download the latest version? (hotfix for file names) Recording would fail on Windows before that.
I just checked on a Windows 10 install I have lying around, and it works as intended there. Check the video I posted for @superlame a few posts back if needed.
If you still cannot get recordings to work, could you please try and launch the tool from cmd or PowerShell, and post the log here after recording and trying to load data?
I just checked on a Windows 10 install I have lying around, and it works as intended there. Check the video I posted for @superlame a few posts back if needed.
If you still cannot get recordings to work, could you please try and launch the tool from cmd or PowerShell, and post the log here after recording and trying to load data?
FR: Je ne vois pas forcément de quels tracés tu parles, mais oui, l'éditeur intégré demande du temps pour créer quelque chose de propre. Le seul logiciel externe dont j'ai entendu parler est l'éditeur pour Blender, peut-être qu'il facilite certaines choses, mais il n'y a pas de solution magique, il faut être prêt à investir du temps.
EN: I don't know what layouts you're talking about, but yeah, LFS's layout editor does require some work to get good-looking layouts. The only (recent) external tool I've heard of is the Blender layout editor, this may help things a bit, but there is no magic solution here, you need to put in the work.
EN: I don't know what layouts you're talking about, but yeah, LFS's layout editor does require some work to get good-looking layouts. The only (recent) external tool I've heard of is the Blender layout editor, this may help things a bit, but there is no magic solution here, you need to put in the work.
Thank you Scawen, this is working just fine now 
OK, that was my bad, I forgot Windows was picky about file names (can't have : in the names).
Here's a link to the fixed version.
Here's a link to the fixed version.
Here you go: https://youtu.be/sj53MN9EkpA
I recorded this on Linux (I only have a Windows virtual machine and nothing really works on it), but it should otherwise work exactly the same.
As long as your cfg.txt is set up properly, you have InSim running in LFS, and the recording tab shows "Connected", you should be able to record and then load data (I renamed the tlm folder so the app would create a new one before recording).
From your last screenshot, nothing seems to be out of the ordinary, so maybe it's something in your cfg.txt? You can also try to run the Telemetry from cmd/powershell, you should see some debug info; maybe something goes wrong when you try to load a lap, if you have laps recorded at all.
Edit: Also, make sure that LFS is not running when you edit the cfg.txt file, as LFS will only read it on startup, and write to it again on shutdown, so it will ignore your changes and then erase them.
I recorded this on Linux (I only have a Windows virtual machine and nothing really works on it), but it should otherwise work exactly the same.
As long as your cfg.txt is set up properly, you have InSim running in LFS, and the recording tab shows "Connected", you should be able to record and then load data (I renamed the tlm folder so the app would create a new one before recording).
From your last screenshot, nothing seems to be out of the ordinary, so maybe it's something in your cfg.txt? You can also try to run the Telemetry from cmd/powershell, you should see some debug info; maybe something goes wrong when you try to load a lap, if you have laps recorded at all.
Edit: Also, make sure that LFS is not running when you edit the cfg.txt file, as LFS will only read it on startup, and write to it again on shutdown, so it will ignore your changes and then erase them.
Last edited by Bokujishin, .
Ah yes, apologies, I did not explain how to use the tool at all, will add that to the first post.
Right now telemetry does not display in real time, you first record a session, and then display it in the telemetry tab by loading a tlm file ( a file is created when you start recording and each time you cross the finish line).
You should not need to run as administrator, tlm files are recorded by default to %appdata%\Godot\app_userdata\LFSTelemetry\tlm, and the file dialog should open there when you try to load a file.
Small gotcha if you record a hotlap replay: crossing the finish line to start the first hotlap does not trigger a new lap event from InSim, so if you start recording "too early", the line will jump across the entire chart. I suggest either waiting for the lap to start (losing a few data points in the process) or slowing the replay down to catch the start of the lap, then resuming normal speed (you can even record in fast forward with no issue as long as your computer manages).
Right now telemetry does not display in real time, you first record a session, and then display it in the telemetry tab by loading a tlm file ( a file is created when you start recording and each time you cross the finish line).
You should not need to run as administrator, tlm files are recorded by default to %appdata%\Godot\app_userdata\LFSTelemetry\tlm, and the file dialog should open there when you try to load a file.
Small gotcha if you record a hotlap replay: crossing the finish line to start the first hotlap does not trigger a new lap event from InSim, so if you start recording "too early", the line will jump across the entire chart. I suggest either waiting for the lap to start (losing a few data points in the process) or slowing the replay down to catch the start of the lap, then resuming normal speed (you can even record in fast forward with no issue as long as your computer manages).
Good to hear you got the visual glitch resolved. By the way, you can leave everything empty in the recording section, it defaults to those values anyway.
The data is recorded through OutSim (and OutGauge for ABS/TC), but unfortunately OutSim only outputs data when you are in cockpit view or custom view, so outside views will result in holes in the data.
The data is recorded through OutSim (and OutGauge for ABS/TC), but unfortunately OutSim only outputs data when you are in cockpit view or custom view, so outside views will result in holes in the data.
Okay, had another go with a different approach: I am now looking for the position of each point within a quadrilateral formed by the left and rights limits defined by the next and previous nodes. Using a nice formula I found online, the figure below plots the previous error (in blue), and the new one (in orange):
This is much better! I'm honestly okay with this result, as the largest deviations are still smaller than the previous "normal" ones, and there are no more large spikes. It's also much more consistent, the noiseless deviations are no more.
I will still need to compare more laps and different tracks, but I am much more confident in this result.
The only problem now, I guess, is that custom .pth files will need to have proper limits for each node, to ensure all quadrilaterals are convex.
This is much better! I'm honestly okay with this result, as the largest deviations are still smaller than the previous "normal" ones, and there are no more large spikes. It's also much more consistent, the noiseless deviations are no more.
I will still need to compare more laps and different tracks, but I am much more confident in this result.
The only problem now, I guess, is that custom .pth files will need to have proper limits for each node, to ensure all quadrilaterals are convex.
I'll have a look but I don't think there is any way to remove hardware acceleration from a Godot app (it is a game engine first and foremost, after all), but the OpenGL version should have better compatibility. I added it to the latest release, direct link here if you prefer.
If this still doesn't work though, I'm not sure I can do anything else.
If this still doesn't work though, I'm not sure I can do anything else.
Weird, never seen that kind of garbled UI with Godot apps. What GPU do you have?
In any case, I just added an OpenGL version (instead of Vulkan) to the v0.2 release, can you give it a try?
In any case, I just added an OpenGL version (instead of Vulkan) to the v0.2 release, can you give it a try?
Adventures in PTH
This thread contains observations, questions (to Scawen and anyone else who can answer), and test results about my fiddling around with PTH files.
I've been working on my telemetry tool for a while now, and got to a point where I need OutSim's indexed distance to display meaningful data (as telemetry is typically plotted against distance along the track, and we need a consistent distance from lap to lap). This works just fine with official layouts, as they do provide this metric, however custom layouts do not. This is a problem as plotting against lap distance can result in variations of several tens of meters from lap to lap, and causes issues such as braking points, among others, to be completely out of sync on my charts.
I decided to have a go at using an already recorded lap to generate my own PTH file, and use it to compute a "corrected distance" that would try to match the indexed distance. Before generating my own files though, I used an existing one to check my calculations. See Figure 1 for an example lap around SO6R with the XRG, with the official indexed distance and my own version. It looks pretty good already, but is shifted slightly. From my observations, the PTH file for SO6R reports node 355 (of 356 total nodes) as the finish line, however when reading the file, it clearly appears that node 18 is closer. After applying a correction for this shifting issue, the two curves line up nicely, but we're not done yet!
Figure 1
Figure 2 shows the difference between my corrected distance and the indexed distance. While the average error is in the order of 20mm, there are several parts where the curve trends away from zero, and sometimes diverges somewhat with a growing amplitude and alternating positive and negative values. We also have 3 very large spikes where the error goes from roughly -0.4m all the way to +0.4m.
Figure 2
So far, I have an explanation for the average error, assuming the more obvious deviations are somewhat symmetrical: when fixing the node offset visible in Figure 1, I chose to set the first data point to a corrected distance of zero. Why? Because I have no way of knowing the proper value here: as I mentioned above, the finish line is closer to node 18 than it is to node 355, and even if the proper node was used, I've read somewhere on this forum that the node is not always (or even not that often) precisely located at the finish line. Note that I haven't checked this for myself, although I could, using the node's coordinates.
The other deviations are more of a problem, and that's where I would like to have Scawen's input, or anyone who can help me here. My corrected distance is computed in a somewhat naive way:
Figure 3
Now we can look at the parts where errors appear in more detail, with annotations on Figure 3 above:
Figure 4
Alright, now I'd like to take a tangent and talk about custom PTH files. Being able to measure the length of a track or custom layout is a very good reason to want a PTH file, since (in my understanding so far) this is how LFS does it for official layouts. To mention just some of the races I took part in, GT2C this year had a custom layout for KY3 and WE2Y, and all E-Challenge races are built on LA1. We need PTH files for track measurement, and I need them for telemetry (still track measurement).
Using my Godot InSim library, I generated a simple square layout on LA1, following the roads (see Figure 4 above). I named that file LA1.pth and put it in the smx folder. I then recorded a lap and plotted the indexed distance and my corrected distance:
Figure 5
Here, the indexed distance goes up, then down (!), then up again. It clearly seems to follow the Y axis coordinate of the car, and it also appears that zero corresponds to the nodes' minimum Y value (-2000 to -1000 in my case, which translates to 0 to 1000). My corrected distance, however, is what I was hoping to obtain, so at least I can get usable data.
@Scawen Would there be any way to allow custom PTH files to be loaded, even just by replacing existing ones in the smx folder?
Going on another tangent here, AI: I know the subject has been tackled before, but I was also hoping to get some AI running on LA1 with the PTH file. However they do not care about it and immediately kill the engine. I also tested a custom PTH file on Blackwood, removing the .knw files while doing so, but the newly generated AI path was the original one, so they just went about the normal track and ignored my custom path.
Is AI path generation not (only) related to .pth and .knw files?
I've been working on my telemetry tool for a while now, and got to a point where I need OutSim's indexed distance to display meaningful data (as telemetry is typically plotted against distance along the track, and we need a consistent distance from lap to lap). This works just fine with official layouts, as they do provide this metric, however custom layouts do not. This is a problem as plotting against lap distance can result in variations of several tens of meters from lap to lap, and causes issues such as braking points, among others, to be completely out of sync on my charts.
I decided to have a go at using an already recorded lap to generate my own PTH file, and use it to compute a "corrected distance" that would try to match the indexed distance. Before generating my own files though, I used an existing one to check my calculations. See Figure 1 for an example lap around SO6R with the XRG, with the official indexed distance and my own version. It looks pretty good already, but is shifted slightly. From my observations, the PTH file for SO6R reports node 355 (of 356 total nodes) as the finish line, however when reading the file, it clearly appears that node 18 is closer. After applying a correction for this shifting issue, the two curves line up nicely, but we're not done yet!
Figure 1
Figure 2 shows the difference between my corrected distance and the indexed distance. While the average error is in the order of 20mm, there are several parts where the curve trends away from zero, and sometimes diverges somewhat with a growing amplitude and alternating positive and negative values. We also have 3 very large spikes where the error goes from roughly -0.4m all the way to +0.4m.
Figure 2
So far, I have an explanation for the average error, assuming the more obvious deviations are somewhat symmetrical: when fixing the node offset visible in Figure 1, I chose to set the first data point to a corrected distance of zero. Why? Because I have no way of knowing the proper value here: as I mentioned above, the finish line is closer to node 18 than it is to node 355, and even if the proper node was used, I've read somewhere on this forum that the node is not always (or even not that often) precisely located at the finish line. Note that I haven't checked this for myself, although I could, using the node's coordinates.
The other deviations are more of a problem, and that's where I would like to have Scawen's input, or anyone who can help me here. My corrected distance is computed in a somewhat naive way:
- For each point of my recorded lap, I look for the PTH node closest to the point's coordinates (right now I loop through all nodes, ideally I should use a quadtree or something).
- I then check the dot product between (next node - closest node) and (current position - closest node); if it is positive, I project the current position onto the line going through the closest node and the next node, otherwise I project it on (previous node - closest node).
- The final step is to get the path distance from the finish line up to the closest node (if dot product is positive, otherwise previous node), and add the distance from that node to the projected position.
- Bonus step: I then apply the correction mentioned above, shifting the data to fix the "reset" partway through the lap and setting the first point to zero.
Figure 3
Now we can look at the parts where errors appear in more detail, with annotations on Figure 3 above:
- 3-8s: First turn and dip, starting right after crossing the tramway tracks. There is some "noise" here, but also a clear trend moving up then down, maybe related to elevation?
- 12-18s: Turn 2, somewhat tight left hander. Noise only here, nodes are more dense in this area, and my line is slightly to the inside of the PTH line.
- 25-33s: The worst offender, chicane + uphill right hander. Extreme spikes (rough location annotated on Figure 3), not sure if 29-31s is just noise or an actual negative error.
- 34-45s: Long wide left hander and highway ramp. Noise as always, but also a clear trend, same as Turn 1, may be related to elevation or deviating from the PTH line.
- 54-57s: The dip, no noise at all here, pure trend error, likely related to elevation.
- 59-65s: Left hairpin, pure noise here.
- 73-77s: Last right turn, pure noise as well.
Figure 4
Alright, now I'd like to take a tangent and talk about custom PTH files. Being able to measure the length of a track or custom layout is a very good reason to want a PTH file, since (in my understanding so far) this is how LFS does it for official layouts. To mention just some of the races I took part in, GT2C this year had a custom layout for KY3 and WE2Y, and all E-Challenge races are built on LA1. We need PTH files for track measurement, and I need them for telemetry (still track measurement).
Using my Godot InSim library, I generated a simple square layout on LA1, following the roads (see Figure 4 above). I named that file LA1.pth and put it in the smx folder. I then recorded a lap and plotted the indexed distance and my corrected distance:
Figure 5
Here, the indexed distance goes up, then down (!), then up again. It clearly seems to follow the Y axis coordinate of the car, and it also appears that zero corresponds to the nodes' minimum Y value (-2000 to -1000 in my case, which translates to 0 to 1000). My corrected distance, however, is what I was hoping to obtain, so at least I can get usable data.
@Scawen Would there be any way to allow custom PTH files to be loaded, even just by replacing existing ones in the smx folder?
Going on another tangent here, AI: I know the subject has been tackled before, but I was also hoping to get some AI running on LA1 with the PTH file. However they do not care about it and immediately kill the engine. I also tested a custom PTH file on Blackwood, removing the .knw files while doing so, but the newly generated AI path was the original one, so they just went about the normal track and ignored my custom path.
Is AI path generation not (only) related to .pth and .knw files?
Last edited by Bokujishin, .
Woops, didn't notice as it displayed fine on my end, fixed the URL, thanks for letting me know.
Telemetry
I am working on a telemetry tool to record and display charts with various data, based on my Godot InSim library. Here's an example screenshot of recorded data:
This tool allows you to record full laps and display the data, or just arbitrary bits of driving by starting and stopping the recording. It uses OutSim and OutGauge for recording, which require either cockpit view or custom view to work properly. This also means you can only record your own car while driving, or any car in an SPR replay (no recording is possible in MPR).
You can find more info and download links on the GitHub repository.
Feel free to give it a try and give some feedback! Please do note that this is still a work in progress though.
Quick guide:
Use the Recording tab to connect to InSim and record data. There is a help button to explain the settings, you can leave everything blank as long as you set the appropriate values in the cfg.txt file.
The app saves .tlm files for each completed lap (incomplete laps work too). After recording, you can use the Telemetry tab to open up to 2 laps (main and reference), the reference lap will appear in gray.
For now I would recommend official layouts for lap comparison, as the charts are plotted against OutSim's indexed distance (the official track length), and as custom layouts lack this indexed distance, they use the distance traveled by the car instead, which varies from lap to lap. I am working on a way to recompute the indexed distance from a .pth file (this part works), and also considering a way to generate a .pth file from a recorded lap (not sure how feasible this one is).
Note that there is no real-time display of telemetry at this time, I'm not sure I will add this.
Right now telemetry does not display in real time, you first record a session, and then display it in the telemetry tab by loading a tlm file ( a file is created when you start recording and each time you cross the finish line).
Note: tlm files are recorded by default to %appdata%\Godot\app_userdata\LFSTelemetry\tlm, and the file dialog should open there when you try to load a file.
Small gotcha if you record a hotlap replay: crossing the finish line to start the first hotlap does not trigger a new lap event from InSim, so if you start recording "too early", the line will jump across the entire chart. I suggest either waiting for the lap to start (losing a few data points in the process) or slowing the replay down to catch the start of the lap, then resuming normal speed (you can even record in fast forward with no issue as long as your computer manages).
Disclaimer: I took some heavy inspiration from MoTeC screenshots I found here and there for chart display.
This tool allows you to record full laps and display the data, or just arbitrary bits of driving by starting and stopping the recording. It uses OutSim and OutGauge for recording, which require either cockpit view or custom view to work properly. This also means you can only record your own car while driving, or any car in an SPR replay (no recording is possible in MPR).
You can find more info and download links on the GitHub repository.
Feel free to give it a try and give some feedback! Please do note that this is still a work in progress though.
Quick guide:
Use the Recording tab to connect to InSim and record data. There is a help button to explain the settings, you can leave everything blank as long as you set the appropriate values in the cfg.txt file.
The app saves .tlm files for each completed lap (incomplete laps work too). After recording, you can use the Telemetry tab to open up to 2 laps (main and reference), the reference lap will appear in gray.
For now I would recommend official layouts for lap comparison, as the charts are plotted against OutSim's indexed distance (the official track length), and as custom layouts lack this indexed distance, they use the distance traveled by the car instead, which varies from lap to lap. I am working on a way to recompute the indexed distance from a .pth file (this part works), and also considering a way to generate a .pth file from a recorded lap (not sure how feasible this one is).
Note that there is no real-time display of telemetry at this time, I'm not sure I will add this.
Right now telemetry does not display in real time, you first record a session, and then display it in the telemetry tab by loading a tlm file ( a file is created when you start recording and each time you cross the finish line).
Note: tlm files are recorded by default to %appdata%\Godot\app_userdata\LFSTelemetry\tlm, and the file dialog should open there when you try to load a file.
Small gotcha if you record a hotlap replay: crossing the finish line to start the first hotlap does not trigger a new lap event from InSim, so if you start recording "too early", the line will jump across the entire chart. I suggest either waiting for the lap to start (losing a few data points in the process) or slowing the replay down to catch the start of the lap, then resuming normal speed (you can even record in fast forward with no issue as long as your computer manages).
Disclaimer: I took some heavy inspiration from MoTeC screenshots I found here and there for chart display.
Last edited by Bokujishin, .
Entry number : 21
Entry name : Pourquoi Pas
Car: XRT
Entered driver (Ingame name / LFSW name / Country) : Cyk / Bokujishin / France
Entry name : Pourquoi Pas
Car: XRT
Entered driver (Ingame name / LFSW name / Country) : Cyk / Bokujishin / France
Oh, never thought about comment spacing, good thing I included the script 
Removing the extra space does work, thanks for the workaround.
Removing the extra space does work, thanks for the workaround.
/run fails to assign buttons with ctrl_fXX and alt_fXX commands
I created 2 scripts to run when I change wheels, so I can quickly reassign buttons.
All standard functions work fine (pit_speed, flash, etc.), but the script throws errors for all ctrl_f10, alt_f10 and such lines:
This is what my script looks like:
All standard functions work fine (pit_speed, flash, etc.), but the script throws errors for all ctrl_f10, alt_f10 and such lines:
wheel_formula : line 10 - Unknown button functionThis is what my script looks like:
// Fanatec wheel with Button Module Endurance
/button 7 left_view
/button 1 right_view
/button 8 horn
/button 12 flash
/button 3 pit_speed
/button 4 tc_disable
/button 10 ignition
/button 23 ctrl_f9 // Indicator left
/button 24 ctrl_f10 // Indicator right
/button 11 ctrl_f11 // Hazard lights
/button 9 ctrl_f12 // Indicators off
/button 2 alt_f1 // toggle headlights
/button 49 alt_f2 // Front ARB +5
/button 50 alt_f3 // Front ARB -5
/button 37 alt_f5 // Rear ARB +5
/button 38 alt_f6 // Rear ARB -5
/button 27 alt_f9 // Status next
/button 32 alt_f10 // Status prev
/button 33 alt_f11 // Brake bal +1
/button 31 alt_f12 // Brake bal -1
I'm going to report myself because that was stupid.
Session AND SERVER of Incident: Race 1
Lap AND MPR timecode of incident (or session time or UTC Time of Day): Lap 1, MPR timecode 2:20
Car(s) involved: 21, 19, collateral damage 51 and 54
Location of Incident: Turn 1
Brief Description of Incident: 21 dives on the inside and collides with 19.
Session AND SERVER of Incident: Race 1
Lap AND MPR timecode of incident (or session time or UTC Time of Day): Lap 1, MPR timecode 2:20
Car(s) involved: 21, 19, collateral damage 51 and 54
Location of Incident: Turn 1
Brief Description of Incident: 21 dives on the inside and collides with 19.
Bokujishin/Read and Understood
GodotInSim is now feature complete after I added InSimRelay and fixed more bugs, so I released version 1.0.0 on GitHub.
If you are interested, you can take a look at this simple demo.
If you are interested, you can take a look at this simple demo.
Okay, so as per usual, it turns out I did make a mistake (though I don't fully understand it): when I refactored my connection code, I changed the PacketPeerUDP socket's bind() method to connect_to_host(); this works perfectly fine for InSim itself, but not for OutGauge, OutSim and the NLP/MCI packets sent via UDP. On the other hand, using bind() triggers an error when connecting InSim (this is the part I don't get), but it works for the others.
I solved this a bit hackily by changing how I connect the socket for InSim and the others, and everything is working so far. Still getting the InSim errors when using the same port, though.
Networking isn't exactly my forte, apologies for the short monologue
I solved this a bit hackily by changing how I connect the socket for InSim and the others, and everything is working so far. Still getting the InSim errors when using the same port, though.
Networking isn't exactly my forte, apologies for the short monologue
Mixed TCP/UDP for InSim
As I'm close to releasing a "production-ready" version of my GodotInSim library, I went back to the details of the TCP/UDP settings in the ISI packet. Using full TCP or full UDP works just fine (UDPPort = 0 for both protocols), however I am having issues with NLP/MCI packets on mixed TCP/UDP, as well as just UDP but using a different port (basically, any time I set UDPPort to something other than zero).
Using Wireshark, I can see the packets are being sent (with port numbers e.g. 29999 -> 30000, haven't checked their contents), however I can't seem to get any packet in Godot (I already checked the UDP socket is connected on the correct port). Additionally, setting UDPPort to the same port as the TCP one causes LFS to throw errors for each NLP/MCI packet sent:
To sum up the possible options:
I will investigate some more on the Godot side and in my code, in case I made a mistake somewhere, but I would appreciate any insight, also the errors do seem to be an issue on LFS's side. I just cannot understand why those packets are not being picked up by Godot, especially in UDP-only mode (cases 5-6 above), as other packets are being sent and received properly.
Using Wireshark, I can see the packets are being sent (with port numbers e.g. 29999 -> 30000, haven't checked their contents), however I can't seem to get any packet in Godot (I already checked the UDP socket is connected on the correct port). Additionally, setting UDPPort to the same port as the TCP one causes LFS to throw errors for each NLP/MCI packet sent:
To sum up the possible options:
- connect using TCP, UDPPort == 0: works fine
- connect using UDP, UDPPort == 0: works fine
- connect using TCP, UDPPort != connection port: cannot get NLP/MCI packets
- connect using TCP, UDPPort == connection port: cannot get NLP/MCI packets, InSim throws errors
- connect using UDP, UDPPort != ISI port: cannot get NLP/MCI packets
- connect using UDP, UDPPort == ISI port: cannot get NLP/MCI packets, InSim throws errors (more of the same error when sending packets)
I will investigate some more on the Godot side and in my code, in case I made a mistake somewhere, but I would appreciate any insight, also the errors do seem to be an issue on LFS's side. I just cannot understand why those packets are not being picked up by Godot, especially in UDP-only mode (cases 5-6 above), as other packets are being sent and received properly.
Nice, I wanted to try Bad Apple in LFS using modded "vehicles" with lights for pixels, but then realized you could only control the local car's lights with this, so the only way I can hope to do something half-decent would be to have 40 people running some "pixels" in sync.
Never thought about using InSim buttons, this looks quite good! Maybe using filled rectangles instead of underscores would make it better?
Never thought about using InSim buttons, this looks quite good! Maybe using filled rectangles instead of underscores would make it better?
FGED GREDG RDFGDR GSFDG