1. 06 2月, 2014 1 次提交
    • J
      Implement output scaling/conversion/downloading · ab4ab957
      jp9000 提交于
      - Implement texture scaling/conversion/downloading for the main view so
        we can finally start getting data to output.
      
        Also, redesign how it works a bit, it will now properly wait one full
        frame for each step in the process:  rendering the main texture,
        scaling the main texture to an output texture, staging/downloading the
        ouput texture, and then outputting that staged data.  This way, the
        GPU will have more than enough time to fully complete each step.
      
      - Fix a bug with OpenGL plugin's texture staging function.  Was using
        glBindBuffer instead of what should have been used:  glBindTexture.
      
      - Change the naming scheme of the variables in default.effect.  It's now
        named with the idea of just "color matrix" in mind instead of "yuv
        matrix", and instead of DrawRGBToYUV, it's now just DrawMatrix.
      ab4ab957
  2. 03 2月, 2014 14 次提交
  3. 02 2月, 2014 4 次提交
    • J
      Add property list callbacks · 458325fc
      jp9000 提交于
      - Add property list callbacks to sources/outputs/encoders so that if
        necessary user interface can be automatically generated or perhaps a
        property list widget can be used for them.
      
      - Change some of the property API names.  obs_property_list_t felt a bit
        awkward when actually using it, so I just renamed it to
        obs_properties_t.
      
      - Removed the getdata/setdata nad getparam/setparam functions from
        sources/services, they will be superseded by the dynamic procedure
        call API.
      458325fc
    • J
      Implement properties definition interface · 0d17d131
      jp9000 提交于
      Implement a properties definition interface to allow modules to export
      general properties associated with objects of libobs.
      
      The properties definition interface allows the option for automatic
      settings UI generation (which will make simple plugins easier to develop
      without the need for user interface), as well as allow real-time
      property editing of values of things like sources/outputs/etc without
      having to open property dialogs.  More property types can be added in
      the future as needed as well.
      0d17d131
    • J
      Simplify/improve UI exporting a bit more · 6f51567c
      jp9000 提交于
      Reduce and simplify the UI export interface.  Having to export functions
      with designated names was a bit silly for this case, it makes more sense
      for inputs/outputs/etc because they have more functions associated with
      them, but in this case the callback can be retrieved simply through the
      enumeration exports.  Makes it a bit easier and a little less awkward
      for this situation.
      
      Also, changed the exports and names to be a bit more consistent,
      labelling them both as either "modal" or "modeless", and changed the UI
      function calls to obs_exec_ui and obs_create_ui to imply modal/modeless
      functionality a bit more.
      6f51567c
    • J
      Add support for modeless UI creation · b31d52d6
      jp9000 提交于
      I realized that I had intended modeless UI to be usable by plugins, but
      it had been pointed out to me that modeless really needs to return a
      pointer/handle to the user interface object that was created.
      b31d52d6
  4. 01 2月, 2014 3 次提交
    • J
      Don't rely on static data · 00a480f7
      jp9000 提交于
      The ui_enum function gets a const struct obs_ui_info **, which basically
      means it expects static data to be used.  I originally had it the other
      way around, but yea, it's probably not a good idea, so I'm going to
      revert back to the original code instead, which doesn't rely on the data
      being static.
      00a480f7
    • J
      Make some minor adjustments to module UI code · 8bb208a0
      jp9000 提交于
      Made it so that enum_ui returns a const pointer to a structure rather
      than require an actual structure.
      
      Changed a few of the descriptions that I missed.
      8bb208a0
    • J
      Add module UI export capability · a12656bd
      jp9000 提交于
      Add the ability to be able to call and use toolkit-specific or
      program-specific user interface in modules.
      
      User interface code can be either bundled with the module, or 'split'
      out in to separate libraries (recommended).
      
      There are three reasons why splitting is recommended:
      
        1.) It allows plugins to be able to create custom user interface for
            each toolkit if desired.
      
        2.) Often, UI will be programmed in one language (the language of the
            toolkit), and core logic may be programmed in another.  This
            allows plugins to keep the languages separated if necessary.
      
        3.) It prevents direct linkage of UI toolkits libraries with core
            module logic.
      
      Splitting is not required, though is recommended if you want your plugin
      to be more flexible with other user interface toolkits or programs.
      
      Will implement a generic properties lookup next, which will be used for
      automatic UI handling so that plugin UI isn't necessarily required.
      a12656bd
  5. 31 1月, 2014 8 次提交
  6. 30 1月, 2014 8 次提交
  7. 29 1月, 2014 2 次提交