1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

DynHUD source code and plugin SDK?

Discussion in 'Automobilista - Links & Resources' started by gongo, Mar 21, 2016.

  1. gongo

    gongo Dan Allongo

    Joined:
    Mar 21, 2016
    Messages:
    370
    Likes Received:
    350
    DynHUD is open source (GPL v2) so any derivative works also need to be open source. Can we have the link to the source code repo for the changes that Reiza have made? Also, it would be helpful to publish a basic plugin SDK similar to the rFactor 1 SDK in the event that any of the telemetry structs have changed.

    Thanks.
     
  2. Dave Stephenson

    Dave Stephenson Administrator Staff Member

    Joined:
    Feb 13, 2016
    Messages:
    130
    Likes Received:
    129
    With regard to to internals plugin data/stuff I've been using the rF Data Acquisition Plugin to get Motec logs out of AMS throughout beta and there haven't been any issues. The data is logged correctly which leads me to believe that they remain the same.

    I'll have to check on DynHUD but I believe that would only be the case if the source was licensed to Reiza under GPL. The authors are of course free to license the work to Reiza under an alternative license if they choose. I'll look into the licensing and whether any changes have been made.
     
  3. Pedro Ramada

    Pedro Ramada New Member

    Joined:
    Mar 24, 2016
    Messages:
    3
    Likes Received:
    0
    It would be great if we can customize the DynHUD position on screen info inside the car!! It would be a step forward for AMS! :) ;)
     
    • Agree Agree x 1
  4. gongo

    gongo Dan Allongo

    Joined:
    Mar 21, 2016
    Messages:
    370
    Likes Received:
    350
    @Dave Stephenson I'm certain something has changed in the structs, yellow flags are not properly reported for the Spotter plugin or for the Renovatio SRD-9c plugin and fanaleds plugin is broken too. All of that seems to have happened sometime back in October or so. Additionally, while it's theoretically possible that somehow the telemetry struct has remained exactly the same, something has caused these plugins to break and there's great demand to have them working again. As far as the whole "source code might have been licensed separately on the side" thing, well, I suppose anything is possible, but I'll file that in the "highly unlikely" category.

    Just to be clear, I don't want any core source code to Automobilista. I don't want any source code to the Automobilista-specific jar file for DynHUD. Any changes made to the publicly-available DynHUD plugin dll must be published under the GPL license as per the GPL license in the original public source code. If in some way the source code was reacquired and relicensed along the way (highly unlikely because GPL doesn't generally allow for this, hence why LGPL exists to allow for this instead) then Reiza only needs to publish the source code changes up to that point.

    I realize that it might seem like an unusual request since most of the user base seem to not have any programming ability, but it's well within the law and I think would benefit the community by allowing fanaleds to be fixed, Renovatio's plugin to be updated, and a new Spotter plugin to be written.


    @Pedro Ramada Perhaps that could be possible with a lot of effort, but I'm interested in DynHUD from the point of view of wanting to write a new Spotter plugin.
     
    • Like Like x 1
  5. gongo

    gongo Dan Allongo

    Joined:
    Mar 21, 2016
    Messages:
    370
    Likes Received:
    350
  6. Marcel Offermans

    Marcel Offermans New Member

    Joined:
    Feb 14, 2016
    Messages:
    8
    Likes Received:
    20
    I can give you an update on this, as one of the two original authors of rFDynHUD. Marvin (the other author) and I did license the code to Reiza using a different license. This is similar to the dual licensing that quite a few other products do, providing it under and open source license (GPL) that can be used for free and as a basis for other open source derivative works (in this case GPL ensures that those will also be open source) and under a commercial license (which is what we did for Reiza).

    As far as providing an SDK for the Plugin API, that is up to Renato. We did add some data but tried to keep it backward compatible. So plugins should still work. If not, we will probably have to look on a case by case basis what is going wrong. For that it helps us to get detailed reports on which plugins do and don't work (which is what you're providing in the posts above). We'll have to investigate.
     
    • Like Like x 2
  7. gongo

    gongo Dan Allongo

    Joined:
    Mar 21, 2016
    Messages:
    370
    Likes Received:
    350
    Good to know. Looking at the original header files provided by ISI, it looks like only a little bit of space is left in the struct for expansion and none of it appears to be Unicode aware. My guess is that running on newer systems causes a shift in the data alignment due to the implicit sizes of pointers and chars possibly being different if it was compiled with Unicode support even though the application remains a 32-bit executable. At least, from what I was able to investigate, that would explain why main car telemetry remains unaffected but functionality might be impaired for events and data occurring later on in the data structure.
     
  8. keith windsor

    keith windsor Active Member

    Joined:
    Mar 9, 2016
    Messages:
    283
    Likes Received:
    109
    If it helps, I reported a change in the spotter plugin behaviour a few months back, just before AMS was released. Although it appears at first glance to still be working normally, there is definitely something wrong.
    The most noticeable change was in the outlap, where the spotter used to say 'I'm looking at your lap times compared to pole, you are one tenth slower in the first sector, you're faster in the second sector, etc....'.
    Now, on the outlap, the spotter is confused, and reports an incorrect first sector time, as if he is not aware it is an outlap.
    There also seems to be a permanent yellow flag problem somewhere near pit exit.
    Since this bug appeared, it has felt to me as if the pit triggers are not being recognised by the spotter.
    I would be over the moon Marcel/gongo, if someone could solve this. For me it really added to the reality of a race event & rounded off my GSC experience, but I have stopped using it since the bug crept in.
     
  9. gongo

    gongo Dan Allongo

    Joined:
    Mar 21, 2016
    Messages:
    370
    Likes Received:
    350
    @Renato Simioni @Marcel Offermans Sounds like we can add the D-BOX Motion plugin to the list of broken plugins... Once all of the legal stuff is worked out, you might want to reconsider your stance on releasing any header files for the telemetry data...
     
  10. Marcel Offermans

    Marcel Offermans New Member

    Joined:
    Feb 14, 2016
    Messages:
    8
    Likes Received:
    20
    Thanks for reporting.
     
  11. DAU Racer

    DAU Racer New Member

    Joined:
    Mar 17, 2016
    Messages:
    7
    Likes Received:
    0
    Is there actually a performance impact by adding more and more plugins? AMS itself akready has a couple, if people add more.... The way how I imagine this works is that all the plugin functions are called after each other, so when you have 10 of them, by when the last one e.g. for telemetry update gets called the vallues might have already changed.

    Would it maybe better for the game and its stability to provide one plugin that actually writes the data into a shared memory segment. (I also started experimenting with plugins and because I am a beginner, very often my plugin kill AMS, which should not be the case, but as I just read data, I would achieve teh same with reading a shared memory segment).
     
  12. gongo

    gongo Dan Allongo

    Joined:
    Mar 21, 2016
    Messages:
    370
    Likes Received:
    350
    I know R3E uses the shared memory paradigm to have external programs read the state, but I think that's a pretty significant departure from the way AMS is setup right now.
    From what I can tell, you won't have a case of plugins "missing" telemetry data, if anything I would expect frame time to increase eventually if you had enough plugins to run through, but that would likely be in the dozens rather than 10. Read-only plugins should be non-blocking anyway.
     
  13. Marcel Offermans

    Marcel Offermans New Member

    Joined:
    Feb 14, 2016
    Messages:
    8
    Likes Received:
    20
    AMS invokes the plugin methods "in process" and effectively such code becomes part of the real-time loop. This means you should be very careful what you do in your plugin. Anything that does I/O or other operations that might block should be avoided. If you have time consuming tasks, don't do that in those plugin methods, but use shared memory or some other way to pass the data quickly from the plugin to other code.

    The real-time loop as a whole must always complete within its assigned time slice. As long as that happens, everything is fine. If not, the whole simulation will fall "out of real-time" which is fatal (especially in an on-line race). Due to the fact that we did increase the frequencies at which we run the simulation and the plugins, they have become more time critical so plugin authors please make sure you test your plugins well.
     
    • Like Like x 1
  14. gongo

    gongo Dan Allongo

    Joined:
    Mar 21, 2016
    Messages:
    370
    Likes Received:
    350
    In that case it may be better to simply export telemetry to a shared memory map handle like R3E and AC currently do.

    Using the sysinternals handle utility, I've noticed that DynHUD uses a memory map handle with the tag name 'DynHUD'. I'm assuming that this is for data exchange with the JVM? Looking at the git code just briefly, I'm not seeing any memory map tag names being passed, in fact it looks like the JVM just gets a pointer and alloc size to read from so I'm guessing this is part of the customization done for Reiza? I admit I haven't spent too much time looking at the code on git so it might be there and I'm just missing it.

    Anyway, if the DynHUD tagged memory map handle contains the telemetry data we're looking for, then maybe we can just read from that segment instead? Or if its structure is somehow proprietary, would you be willing to add a shared memory map that exports the rFactor 1 telemetry struct? I've been playing with the R3E shared memory map and even reading it from Python is fairly trivial, so this opens up the opportunity to write non-blocking extensions in non-native code without having to worry about performance impacts.

    I'll be looking at the sample rF1 plugin code this weekend to see if I can get it to compile and export a shared handle too, but being that I have no idea if/how the telemetry bits have changed, it could be dicey. Looking at the old struct, it seems to use array pointers and default packing so we'll likely have to define some static array sizes and pragma pack 1 to get a reliable and predictable memory size.

    EDIT: Here's my repo for reading R3E's shared memory map from Python and then running an instrument display from it: GitHub - dallongo/pySRD9c: Python interface for sim racing dashboard display
     
  15. Marcel Offermans

    Marcel Offermans New Member

    Joined:
    Feb 14, 2016
    Messages:
    8
    Likes Received:
    20
    If we were starting from scratch, we could argue about the benefits and disadvantages of both approaches. Right now I would not want to break backward compatibility of existing plugins. Furthermore, the API currently does more than just provide data. You can generate all kinds of feedback as well (buttons, force feedback, spotter messages, etc.). Doing that in a more asychronous, memory mapped interaction would be harder.

    The memory map you've found is internal to DynHUD. It is used to communicate between the plugin and the JVM that is embedded in the D3D9.DLL. You could use that as an example of how to create such a setup and create a memory map yourself. If you open source that and provide ways to access it from different languages, that might be of benefit to others.
     
    • Like Like x 2
  16. gongo

    gongo Dan Allongo

    Joined:
    Mar 21, 2016
    Messages:
    370
    Likes Received:
    350
    Okey dokey. I guess I'll be spending the weekend writing this thing for AMS. And of course it'll be open source, I'm a Linux dev. ;)
     
    • Like Like x 3
  17. gongo

    gongo Dan Allongo

    Joined:
    Mar 21, 2016
    Messages:
    370
    Likes Received:
    350
    It was a busy weekend but I finally got around to it. I'll make a new thread for my plugin.
     
    • Like Like x 4
  18. Will Mazeo

    Will Mazeo Active Member

    Joined:
    Mar 8, 2016
    Messages:
    510
    Likes Received:
    133
    quick question: does DynHUD support gif?
     
  19. gongo

    gongo Dan Allongo

    Joined:
    Mar 21, 2016
    Messages:
    370
    Likes Received:
    350
    A quick check of the old source code shows support for PNG. You should be able to open your GIF in MSPaint and save it out as PNG to have it work with DynHUD.
     
  20. Will Mazeo

    Will Mazeo Active Member

    Joined:
    Mar 8, 2016
    Messages:
    510
    Likes Received:
    133
    Thanks, does not work. If save on MSPaint it loses transparency, if save on GIMP it becomes just an image. No problems tho. :)
     

Share This Page