From ebb98526a8bac1ed3950d7eec8141c39a859dcf4 Mon Sep 17 00:00:00 2001 From: Dave Clark Date: Tue, 1 Aug 2017 21:55:59 -0400 Subject: test 2 --- README.md | 306 +----------------------------- doc/html/_m_a_i_n_p_a_g_e_8md_source.html | 101 ++++++++++ doc/html/index.html | 7 +- doc/html/navtreedata.js | 2 +- doc/html/search/all_2.js | 3 +- doc/html/search/all_9.js | 1 - doc/html/search/pages_1.js | 2 +- doc/html/search/searchdata.js | 2 +- 8 files changed, 115 insertions(+), 309 deletions(-) create mode 100644 doc/html/_m_a_i_n_p_a_g_e_8md_source.html diff --git a/README.md b/README.md index a3971e7..f1ba6c9 100644 --- a/README.md +++ b/README.md @@ -3,7 +3,8 @@ # NVIDIA GeForce Experience SDK # {#section_main} * Version: 1.0.0.d2a45f0d -* Built for GFE Version: 3.9.0.37 +* Built against GFE Version: 3.9.0.37 +* GeForce Experience minimum version: 3.8 * See [Changelog](\ref section_changelog) ## At a Glance {#section_glance} @@ -12,305 +13,8 @@ The GeForce SDK (GfeSDK) is a means for games to integrate with ShadowPlay Highl and screenshots and present the resulting highlights back to users for viewing and sharing. GfeSDK will add other features over time that benefit from games and applications working in concert with GFE functionality. -![Shadowplay Highlights](/img/gfesdk_highlights.png) +![Shadowplay Highlights](./doc/html/gfesdk_highlights.png) -### Software Stack {#section_stack} +## Development Guide -![Software Stack](/img/gfesdk_block.png) - -An application integrates with the GfeSDK via either the provided Unreal Engine 4 plug-in, C++ interface, or C interface. This integration, via the SDK, calls a compatible GFE 3.0 release. - -The developer (or associated publisher) distributes the application (including associated SDK libraries). - -NVIDIA distributes a GfeSDK package coupled with GfeSDK-compatible GFE releases. GFE maintains backwards SDK-compatibility; games integrated with older SDKs work with newer GFE releases. - -### GfeSDK Package {#section_package} - -The distribution will look like the following -``` -. -+-- README.md -+-- LICENSE -+-- doc -| +-- index.html # Points to the deeper index.html -| +-- html -| | +-- index.html -| | ... -+-- include -| +-- gfesdk -| | +-- bindings -| | | +-- cpp # C++ bindings that sit on top of C API -| | +-- isdk.h -| | ... -+-- lib -| +-- win32 -| | +-- GfeSDK.lib # x86 Import library for linking -| +-- win64 -| | +-- GfeSDK.lib # x64 Import library for linking -+-- redist -| +-- win32 -| | +-- GfeSDK.dll # x86 DLL to be shipped with the game -| +-- win64 -| | +-- GfeSDK.dll # x64 DLL to be shipped with the game -+-- samples -``` - -### Compiling And Linking {#section_compiling} - -To compile, add the ./include (not the ./include/gfesdk) directory to the compiler's list of includes. The import libraries -are found in the ./lib folder and can be used to link the symbols into the game's executable. The proper GfeSDK.dll file -will need to be distributed with the game in a place that the game can find it. - -The C++ bindings are currently distributed in header-only form to avoid ABI incompatibilities between different compiler -versions. The linking and include steps are the same. - -## Using GfeSDK ## {#section_using} - -Creation and destruction of an SDK instance is a prerequisite to making calls -to the SDK. The means of creating and destroying an instance depend on which -integration mechanism the client employs: - -See [Core header documentation](\ref isdk.h) - -See [Highlights header documentation](\ref ihighlights.h) - -### Creation and Release {#section_example_create} - -#### C++ Bindings - -\snippet GfeSDKDemo.cpp Creation CPP - -// After using GfeSDK - -\snippet GfeSDKDemo.cpp Release CPP - -#### C API - -\snippet GfeSDKDemo.cpp Creation - -// After using GfeSDK - -\snippet GfeSDKDemo.cpp Release - -### Request Permissions {#section_example_permission} - -The Create call will inform the app if one or more scopes require user -permission. If so, make this call. It will display the overlay UI. - -#### C++ Bindings - -\snippet GfeSDKDemo.cpp Permissions CPP - -#### C API - -\snippet GfeSDKDemo.cpp Permissions - -### Configure Highlights {#section_example_highlightsconfigure} - -This only needs to happen once ever. It is persistent. It could even happen -during game installation. - -#### C++ Bindings - -\snippet GfeSDKDemo.cpp ConfigureHighlights CPP - -#### C API - -\snippet GfeSDKDemo.cpp ConfigureHighlights - -### Groups and Saving Highlights {#section_Example_highlights} - -#### C++ Bindings - -\snippet GfeSDKDemo.cpp OpenGroup CPP -\snippet GfeSDKDemo.cpp SaveVideo CPP -\snippet GfeSDKDemo.cpp CloseGroup CPP - -#### C API - -\snippet GfeSDKDemo.cpp OpenGroup -\snippet GfeSDKDemo.cpp SaveVideo -\snippet GfeSDKDemo.cpp CloseGroup - -### Open Highlight Summary {#section_example_summary} - -#### C++ Bindings - -\snippet GfeSDKDemo.cpp OpenSummary CPP - -#### C API - -\snippet GfeSDKDemo.cpp OpenSummary - -## Concepts {#section_concepts} - -The GfeSDK is composed of two parts, the client/app, and the backend/server. -This distribution contains GfeSDK.dll which represents the client/app part. -The end-user downloads GFE onto their machine. The GFE package includes the -backend pieces necessary to support the calls coming from the client. See -\ref section_version for more information regarding this communication. - -Calls made will be serialized. Therefore, if the app makes two consecutive -calls to NVGSDK_Highlights_OpenGroup and then either -NVGSDK_Highlights_SetVideoHighlight or NVGSDK_Highlights_SetScreenshotHighlight, -before receiving the callback from open group, the set highlight call will -function normally. If open group succeeded, then the set highlights calls will -succeed as well. If it failed, the set highlights calls will fail, as there -will be no valid group to assign them to. - -### Strings {#section_strings} -All strings are to be provided in single-byte width, UTF-8 encoded. - -### Versioning {#section_version} -Because there are two different parts, and the client / user's machine may -be mismatched at times, the game should be aware of the versioning system. -It's GfeSDK's goal to make this as seamless as possible, but there could still -be compatibility issues to be aware of. - -The GfeSDK version contains 4 parts, MAJOR.MINOR.BUILD.HASH. The BUILD and HASH -components are descriptive and don't have any effect on functionality. The -MAJOR component identifies overall compatibility. If the client and server -mismatch on the major version number, no communication is possible. **There -are no current plans to update from 1, breaking communication**. The major -version number gives a way to show incompatibility if the fundamental -architecture of GFE ever changes. The minor version number indicates feature -compatibility. When a new feature gets added / modified on the SDK, the minor -version number will be bumped. This means that for older games / newer GFE -installations, the game is simply missing out on newer features. This will -generally not be a problem. For a game with a newer version of the GfeSDK, -and a user with an older installation of GFE, some features may not function, -and the user should be encouraged to update GFE. - -With that in mind, here are the possible return values from \ref NVGSDK_Create, -with regards to versioning: -* **NVGSDK_SUCCESS** - Perfect version match -* **NVGSDK_SUCCESS_OLD_GFE** - Minor version mismatch. User has an older -version of GFE installed. Newer features distributed by the game will not -function properly until the user upgrades. -* **NVGSDK_SUCCESS_OLD_SDK** - Minor version mismatch. -Game is distributing an older version of GfeSDK. -Game could be missing out on latest features, but no compatibily issue. -* **NVGSDK_ERR_GFE_VERSION** - Major version mismatch. User has a GFE -installation that predates the GfeSDK. User must upgrade to get functionality. -* **NVGSDK_ERR_SDK_VERSION** - Major version mismatch. GFE has changed -fundamentally. **There are no plans to do this. This is to cover all bases** - -### Permissions {#section_permissions} -Certain actions require permission from the user. For example, recording video -for Highlights requires the user to agree to the recording. To achieve this, -the app must know what features it wishes to enable. It will pass these -"scopes" into the NVGSDK_Create call via NVGSDK_CreateInputParams. Consider -the typical Highlights case as an example. The app will pass in a list of -the scopes NVGSDK_SCOPE_HIGHLIGHTS, NVGSDK_SCOPE_HIGHLIGHTS_VIDEO, and -NVGSDK_SCOPE_SCREENSHOT. The first of these is required in order for any -of the NVGSDK_Highlights_* calls to succeed and send a message to the server. -It will allocate the resources required in the DLL and on the server in order -to achieve this. The second of these permissions is required in order to -capture video of the gameplay, and the final is to capture a screenshot. - -The first time the user runs the game, and the game calls NVGSDK_Create(...), -and passes in these three permissions, the game might receive back that -NVGSDK_SCOPE_HIGHLIGHTS has been granted permission implicitly, but that -NVGSDK_SCOPE_HIGHLIGHTS_VIDEO and NVGSDK_SCOPE_HIGHLIGHTS_SCREENSHOT -currently have "must ask" permission. In other words, the game must ask -GFE for permission to record video before it will succeed in doing so. To -achieve this, the game will call NVGSDK_RequestPermissionsAsync with two -scopes in the list, NVGSDK_SCOPE_HIGHLIGHTS_VIDEO and -NVGSDK_SCOPE_HIGHLIGHTS_SCREENSHOT. It's not necessary to request permission -for a scope that has implicitly been granted permission already. - -The call to NVGSDK_RequestPermissions is required because it will trigger -GFE to put up an \ref section_igo. The game might not want this to occur -during NVGSDK_Create time. Once called, the user will see the overlay -pop up, asking them for permission. - -![Highlights Permission](/img/permission.png) - -The async callback will be triggered as soon as the message is processed -by the GFE backend. The user will be able to accept, deny, or defer the -request. If the user accepts or denies the request, the app will recieve -a \ref NVGSDK_NOTIFICATION_PERMISSIONS_CHANGED notification with the results. -If \ref NVGSDK_RequestPermissionsAsync is called again when the permission is -already granted or denied, the overlay will not be displayed a second time. -The user can reverse their decision in either case later on in GFE3 on -the games details page. - -### Asynchronous Calls {#section_async} -Most of the calls to GfeSDK are asynchronous. This is due to the client/server -architecture described in \ref section_concepts. For each asynchronous call, a -callback and an opaque void* context are passed in as arguments. If the app -does not care or desire to know what happens to the call, is it fine to pass -in NULL. If the app does care, supply a callback of the proper type, and -optionally a pointer as a context to receive back during the callback. - -The callbacks are properly typed. For callbacks that return nothing but the -return value and context, a \ref NVGSDK_EmptyCallback is passed in. For -versions that do return data, a typed callback is passed in, such as -\ref NVGSDK_GetUILanguageCallback. - -The callback will be called on one of three threads, depending on the -situation. If NVGSDK_CreateInputParams::pollForCallbacks is set to false -during creation, the callback will always occur on a GfeSDK controller thread. -If the app desires callback to occur on their own thread, true is passed in -instead. In that case, the callback will occur on the thread that calls -\ref NVGSDK_Poll. The exception is that during \ref NVGSDK_Destroy, GfeSDK -pushes out all remaining callbacks. If the app is awaiting any callbacks -during this time, they will be called on the same thread that called -NVGSDK_Destroy. Usually, this will be the same thread that calls NVGSDK_Poll, -so it shouldn't cause any surprises, but it's something to be aware of. See -\ref section_threading for more information - -**Note:** There is currently a limitation in the GfeSDK backend that depends -on game frames being rendered during certain API calls. Therefore, the game -cannot block the render loop while awaiting an asynchronous callback. Doing -so will result in a deadlock. - -### Notifications ### {#section_notifications} - -In addition to the async callbacks that most of the APIs accept as an argument, -the app can also register to recieve unsolicited notifications when certain -events occur. For example, the app might want to know when the user can -given / removed permission for recording video from the app, either through -the permissions dialog, or via GFE3. See \ref NVGSDK_CreateInputParams and -\ref NVGSDK_NotificationType - -This notification will get called on either the GfeSDK callback thread, or -the thread that calls \ref NVGSDK_Poll, depending on params passed in to -\ref NVGSDK_Create. See \ref section_threading for more information. - -### Threading {#section_threading} -There are two different threading models that may be used. The model used -depends on the value passed in to \ref NVGSDK_CreateInputParams - -##### GfeSDK Controller Callback Model -In this model, all callbacks will occur as soon as they are processed on the -internal GfeSDK callback thread. - -##### Polling Model -The app can choose to use this model if it wants to take action during the -callback that depend on being on the game loop. Callbacks are queued up, and -executed when the app calls \ref NVGSDK_Poll. This means that callbacks will -be blocked indefinitely if that API is never called. - -The exception occurs during \ref NVGSDK_Destroy. Because the normal case is -to make NVGSDK_Destroy and NVGSDK_Poll calls from the same thread, GfeSDK -can't block and wait for another poll call. All remaining callbacks will be -executed during \ref NVGSDK_Destroy. See \ref section_async for more info. - -### In Game Overlay {#section_igo} -![In Game Overlay](/img/igo.png) - -The In-Game overlay can be used by the user to change Highlights settings, and -view Highlights that have been saved to the gallery. It's also used to display -the permissions dialog from \ref NVGSDK_RequestPermissionsAsync, and the -group summary from \ref NVGSDK_OpenGroupSummaryAsync. The user can open it -up by themselves using the default keybinding Alt+Z - -### Logging {#section_log} -By default, GfeSDK stores its own logs for problem triage in -%LOCALAPPDATA%\NVIDIA Corporation\GfeSDK. This behavior can be adjusted by -the following calls: - -* \ref NVGSDK_SetLogLevel -* \ref NVGSDK_AttachLogListener -* \ref NVGSDK_SetListenerLogLevel +See the documentation [here](./doc/index.html) diff --git a/doc/html/_m_a_i_n_p_a_g_e_8md_source.html b/doc/html/_m_a_i_n_p_a_g_e_8md_source.html new file mode 100644 index 0000000..2b3b06f --- /dev/null +++ b/doc/html/_m_a_i_n_p_a_g_e_8md_source.html @@ -0,0 +1,101 @@ + + + + + + + + +NVIDIAGeForceExperienceSDK: MAINPAGE.md Source File + + + + + + + + + + + + + + + +
+
+ + + + + + +
+
NVIDIAGeForceExperienceSDK +
+
+
+ + + + + + + +
+
+ +
+
+
+ +
+ +
+
+ + +
+ +
+ +
+
+
MAINPAGE.md
+
+
+
1 # Development Guide # {#mainpage}
2 
3 # NVIDIA GeForce Experience SDK # {#section_main}
4 
5 * Version: 1.0.0.d2a45f0d
6 * Built against GFE Version: 3.9.0.37
7 * GeForce Experience minimum version: 3.8
8 * See [Changelog](\ref section_changelog)
9 
10 ## At a Glance {#section_glance}
11 
12 The GeForce SDK (GfeSDK) is a means for games to integrate with ShadowPlay Highlights allowing them to capture videos
13 and screenshots and present the resulting highlights back to users for viewing and sharing. GfeSDK will add other features
14 over time that benefit from games and applications working in concert with GFE functionality.
15 
16 ![Shadowplay Highlights](/img/gfesdk_highlights.png)
17 
18 ### Software Stack {#section_stack}
19 
20 ![Software Stack](/img/gfesdk_block.png)
21 
22 An application integrates with the GfeSDK via either the provided Unreal Engine 4 plug-in, C++ interface, or C interface. This integration, via the SDK, calls a compatible GFE 3.0 release.
23 
24 The developer (or associated publisher) distributes the application (including associated SDK libraries).
25 
26 NVIDIA distributes a GfeSDK package coupled with GfeSDK-compatible GFE releases. GFE maintains backwards SDK-compatibility; games integrated with older SDKs work with newer GFE releases.
27 
28 ### GfeSDK Package {#section_package}
29 
30 The distribution will look like the following
31 ```
32 .
33 +-- README.md
34 +-- LICENSE
35 +-- doc
36 | +-- index.html # Points to the deeper index.html
37 | +-- html
38 | | +-- index.html
39 | | ...
40 +-- include
41 | +-- gfesdk
42 | | +-- bindings
43 | | | +-- cpp # C++ bindings that sit on top of C API
44 | | +-- isdk.h
45 | | ...
46 +-- lib
47 | +-- win32
48 | | +-- GfeSDK.lib # x86 Import library for linking
49 | +-- win64
50 | | +-- GfeSDK.lib # x64 Import library for linking
51 +-- redist
52 | +-- win32
53 | | +-- GfeSDK.dll # x86 DLL to be shipped with the game
54 | +-- win64
55 | | +-- GfeSDK.dll # x64 DLL to be shipped with the game
56 +-- samples
57 ```
58 
59 ### Compiling And Linking {#section_compiling}
60 
61 To compile, add the ./include (not the ./include/gfesdk) directory to the compiler's list of includes. The import libraries
62 are found in the ./lib folder and can be used to link the symbols into the game's executable. The proper GfeSDK.dll file
63 will need to be distributed with the game in a place that the game can find it.
64 
65 The C++ bindings are currently distributed in header-only form to avoid ABI incompatibilities between different compiler
66 versions. The linking and include steps are the same.
67 
68 ## Using GfeSDK ## {#section_using}
69 
70 Creation and destruction of an SDK instance is a prerequisite to making calls
71 to the SDK. The means of creating and destroying an instance depend on which
72 integration mechanism the client employs:
73 
74 See [Core header documentation](\ref isdk.h)
75 
76 See [Highlights header documentation](\ref ihighlights.h)
77 
78 ### Creation and Release {#section_example_create}
79 
80 #### C++ Bindings
81 
82 \snippet GfeSDKDemo.cpp Creation CPP
83 
84 // After using GfeSDK
85 
86 \snippet GfeSDKDemo.cpp Release CPP
87 
88 #### C API
89 
90 \snippet GfeSDKDemo.cpp Creation
91 
92 // After using GfeSDK
93 
94 \snippet GfeSDKDemo.cpp Release
95 
96 ### Request Permissions {#section_example_permission}
97 
98 The Create call will inform the app if one or more scopes require user
99 permission. If so, make this call. It will display the overlay UI.
100 
101 #### C++ Bindings
102 
103 \snippet GfeSDKDemo.cpp Permissions CPP
104 
105 #### C API
106 
107 \snippet GfeSDKDemo.cpp Permissions
108 
109 ### Configure Highlights {#section_example_highlightsconfigure}
110 
111 This only needs to happen once ever. It is persistent. It could even happen
112 during game installation.
113 
114 #### C++ Bindings
115 
116 \snippet GfeSDKDemo.cpp ConfigureHighlights CPP
117 
118 #### C API
119 
120 \snippet GfeSDKDemo.cpp ConfigureHighlights
121 
122 ### Groups and Saving Highlights {#section_Example_highlights}
123 
124 #### C++ Bindings
125 
126 \snippet GfeSDKDemo.cpp OpenGroup CPP
127 \snippet GfeSDKDemo.cpp SaveVideo CPP
128 \snippet GfeSDKDemo.cpp CloseGroup CPP
129 
130 #### C API
131 
132 \snippet GfeSDKDemo.cpp OpenGroup
133 \snippet GfeSDKDemo.cpp SaveVideo
134 \snippet GfeSDKDemo.cpp CloseGroup
135 
136 ### Open Highlight Summary {#section_example_summary}
137 
138 #### C++ Bindings
139 
140 \snippet GfeSDKDemo.cpp OpenSummary CPP
141 
142 #### C API
143 
144 \snippet GfeSDKDemo.cpp OpenSummary
145 
146 ## Concepts {#section_concepts}
147 
148 The GfeSDK is composed of two parts, the client/app, and the backend/server.
149 This distribution contains GfeSDK.dll which represents the client/app part.
150 The end-user downloads GFE onto their machine. The GFE package includes the
151 backend pieces necessary to support the calls coming from the client. See
152 \ref section_version for more information regarding this communication.
153 
154 Calls made will be serialized. Therefore, if the app makes two consecutive
155 calls to NVGSDK_Highlights_OpenGroup and then either
156 NVGSDK_Highlights_SetVideoHighlight or NVGSDK_Highlights_SetScreenshotHighlight,
157 before receiving the callback from open group, the set highlight call will
158 function normally. If open group succeeded, then the set highlights calls will
159 succeed as well. If it failed, the set highlights calls will fail, as there
160 will be no valid group to assign them to.
161 
162 ### Strings {#section_strings}
163 All strings are to be provided in single-byte width, UTF-8 encoded.
164 
165 ### Versioning {#section_version}
166 Because there are two different parts, and the client / user's machine may
167 be mismatched at times, the game should be aware of the versioning system.
168 It's GfeSDK's goal to make this as seamless as possible, but there could still
169 be compatibility issues to be aware of.
170 
171 The GfeSDK version contains 4 parts, MAJOR.MINOR.BUILD.HASH. The BUILD and HASH
172 components are descriptive and don't have any effect on functionality. The
173 MAJOR component identifies overall compatibility. If the client and server
174 mismatch on the major version number, no communication is possible. **There
175 are no current plans to update from 1, breaking communication**. The major
176 version number gives a way to show incompatibility if the fundamental
177 architecture of GFE ever changes. The minor version number indicates feature
178 compatibility. When a new feature gets added / modified on the SDK, the minor
179 version number will be bumped. This means that for older games / newer GFE
180 installations, the game is simply missing out on newer features. This will
181 generally not be a problem. For a game with a newer version of the GfeSDK,
182 and a user with an older installation of GFE, some features may not function,
183 and the user should be encouraged to update GFE.
184 
185 With that in mind, here are the possible return values from \ref NVGSDK_Create,
186 with regards to versioning:
187 * **NVGSDK_SUCCESS** - Perfect version match
188 * **NVGSDK_SUCCESS_OLD_GFE** - Minor version mismatch. User has an older
189 version of GFE installed. Newer features distributed by the game will not
190 function properly until the user upgrades.
191 * **NVGSDK_SUCCESS_OLD_SDK** - Minor version mismatch.
192 Game is distributing an older version of GfeSDK.
193 Game could be missing out on latest features, but no compatibily issue.
194 * **NVGSDK_ERR_GFE_VERSION** - Major version mismatch. User has a GFE
195 installation that predates the GfeSDK. User must upgrade to get functionality.
196 * **NVGSDK_ERR_SDK_VERSION** - Major version mismatch. GFE has changed
197 fundamentally. **There are no plans to do this. This is to cover all bases**
198 
199 ### Permissions {#section_permissions}
200 Certain actions require permission from the user. For example, recording video
201 for Highlights requires the user to agree to the recording. To achieve this,
202 the app must know what features it wishes to enable. It will pass these
203 "scopes" into the NVGSDK_Create call via NVGSDK_CreateInputParams. Consider
204 the typical Highlights case as an example. The app will pass in a list of
205 the scopes NVGSDK_SCOPE_HIGHLIGHTS, NVGSDK_SCOPE_HIGHLIGHTS_VIDEO, and
206 NVGSDK_SCOPE_SCREENSHOT. The first of these is required in order for any
207 of the NVGSDK_Highlights_* calls to succeed and send a message to the server.
208 It will allocate the resources required in the DLL and on the server in order
209 to achieve this. The second of these permissions is required in order to
210 capture video of the gameplay, and the final is to capture a screenshot.
211 
212 The first time the user runs the game, and the game calls NVGSDK_Create(...),
213 and passes in these three permissions, the game might receive back that
214 NVGSDK_SCOPE_HIGHLIGHTS has been granted permission implicitly, but that
215 NVGSDK_SCOPE_HIGHLIGHTS_VIDEO and NVGSDK_SCOPE_HIGHLIGHTS_SCREENSHOT
216 currently have "must ask" permission. In other words, the game must ask
217 GFE for permission to record video before it will succeed in doing so. To
218 achieve this, the game will call NVGSDK_RequestPermissionsAsync with two
219 scopes in the list, NVGSDK_SCOPE_HIGHLIGHTS_VIDEO and
220 NVGSDK_SCOPE_HIGHLIGHTS_SCREENSHOT. It's not necessary to request permission
221 for a scope that has implicitly been granted permission already.
222 
223 The call to NVGSDK_RequestPermissions is required because it will trigger
224 GFE to put up an \ref section_igo. The game might not want this to occur
225 during NVGSDK_Create time. Once called, the user will see the overlay
226 pop up, asking them for permission.
227 
228 ![Highlights Permission](/img/permission.png)
229 
230 The async callback will be triggered as soon as the message is processed
231 by the GFE backend. The user will be able to accept, deny, or defer the
232 request. If the user accepts or denies the request, the app will recieve
233 a \ref NVGSDK_NOTIFICATION_PERMISSIONS_CHANGED notification with the results.
234 If \ref NVGSDK_RequestPermissionsAsync is called again when the permission is
235 already granted or denied, the overlay will not be displayed a second time.
236 The user can reverse their decision in either case later on in GFE3 on
237 the games details page.
238 
239 ### Asynchronous Calls {#section_async}
240 Most of the calls to GfeSDK are asynchronous. This is due to the client/server
241 architecture described in \ref section_concepts. For each asynchronous call, a
242 callback and an opaque void* context are passed in as arguments. If the app
243 does not care or desire to know what happens to the call, is it fine to pass
244 in NULL. If the app does care, supply a callback of the proper type, and
245 optionally a pointer as a context to receive back during the callback.
246 
247 The callbacks are properly typed. For callbacks that return nothing but the
248 return value and context, a \ref NVGSDK_EmptyCallback is passed in. For
249 versions that do return data, a typed callback is passed in, such as
250 \ref NVGSDK_GetUILanguageCallback.
251 
252 The callback will be called on one of three threads, depending on the
253 situation. If NVGSDK_CreateInputParams::pollForCallbacks is set to false
254 during creation, the callback will always occur on a GfeSDK controller thread.
255 If the app desires callback to occur on their own thread, true is passed in
256 instead. In that case, the callback will occur on the thread that calls
257 \ref NVGSDK_Poll. The exception is that during \ref NVGSDK_Destroy, GfeSDK
258 pushes out all remaining callbacks. If the app is awaiting any callbacks
259 during this time, they will be called on the same thread that called
260 NVGSDK_Destroy. Usually, this will be the same thread that calls NVGSDK_Poll,
261 so it shouldn't cause any surprises, but it's something to be aware of. See
262 \ref section_threading for more information
263 
264 **Note:** There is currently a limitation in the GfeSDK backend that depends
265 on game frames being rendered during certain API calls. Therefore, the game
266 cannot block the render loop while awaiting an asynchronous callback. Doing
267 so will result in a deadlock.
268 
269 ### Notifications ### {#section_notifications}
270 
271 In addition to the async callbacks that most of the APIs accept as an argument,
272 the app can also register to recieve unsolicited notifications when certain
273 events occur. For example, the app might want to know when the user can
274 given / removed permission for recording video from the app, either through
275 the permissions dialog, or via GFE3. See \ref NVGSDK_CreateInputParams and
276 \ref NVGSDK_NotificationType
277 
278 This notification will get called on either the GfeSDK callback thread, or
279 the thread that calls \ref NVGSDK_Poll, depending on params passed in to
280 \ref NVGSDK_Create. See \ref section_threading for more information.
281 
282 ### Threading {#section_threading}
283 There are two different threading models that may be used. The model used
284 depends on the value passed in to \ref NVGSDK_CreateInputParams
285 
286 ##### GfeSDK Controller Callback Model
287 In this model, all callbacks will occur as soon as they are processed on the
288 internal GfeSDK callback thread.
289 
290 ##### Polling Model
291 The app can choose to use this model if it wants to take action during the
292 callback that depend on being on the game loop. Callbacks are queued up, and
293 executed when the app calls \ref NVGSDK_Poll. This means that callbacks will
294 be blocked indefinitely if that API is never called.
295 
296 The exception occurs during \ref NVGSDK_Destroy. Because the normal case is
297 to make NVGSDK_Destroy and NVGSDK_Poll calls from the same thread, GfeSDK
298 can't block and wait for another poll call. All remaining callbacks will be
299 executed during \ref NVGSDK_Destroy. See \ref section_async for more info.
300 
301 ### In Game Overlay {#section_igo}
302 ![In Game Overlay](/img/igo.png)
303 
304 The In-Game overlay can be used by the user to change Highlights settings, and
305 view Highlights that have been saved to the gallery. It's also used to display
306 the permissions dialog from \ref NVGSDK_RequestPermissionsAsync, and the
307 group summary from \ref NVGSDK_OpenGroupSummaryAsync. The user can open it
308 up by themselves using the default keybinding Alt+Z
309 
310 ### Logging {#section_log}
311 By default, GfeSDK stores its own logs for problem triage in
312 %LOCALAPPDATA%\NVIDIA Corporation\GfeSDK. This behavior can be adjusted by
313 the following calls:
314 
315 * \ref NVGSDK_SetLogLevel
316 * \ref NVGSDK_AttachLogListener
317 * \ref NVGSDK_SetListenerLogLevel
+
+ + + + + diff --git a/doc/html/index.html b/doc/html/index.html index 36f963a..6df6e5d 100644 --- a/doc/html/index.html +++ b/doc/html/index.html @@ -6,7 +6,7 @@ -NVIDIAGeForceExperienceSDK: Overview +NVIDIAGeForceExperienceSDK: Development Guide @@ -82,14 +82,15 @@ $(document).ready(function(){initNavTree('index.html','');});
-
Overview
+
Development Guide

NVIDIA GeForce Experience SDK

  • Version: 1.0.0.d2a45f0d
    • -
  • Built for GFE Version: 3.9.0.37
    • +
  • Built against GFE Version: 3.9.0.37
    • +
  • GeForce Experience minimum version: 3.8
  • See Changelog

diff --git a/doc/html/navtreedata.js b/doc/html/navtreedata.js index 3a0487d..10472c0 100644 --- a/doc/html/navtreedata.js +++ b/doc/html/navtreedata.js @@ -1,7 +1,7 @@ var NAVTREE = [ [ "NVIDIAGeForceExperienceSDK", "index.html", [ - [ "Overview", "index.html", [ + [ "Development Guide", "index.html", [ [ "NVIDIA GeForce Experience SDK", "index.html#section_main", [ [ "At a Glance", "index.html#section_glance", [ [ "Software Stack", "index.html#section_stack", null ], diff --git a/doc/html/search/all_2.js b/doc/html/search/all_2.js index 2e19255..b0fda36 100644 --- a/doc/html/search/all_2.js +++ b/doc/html/search/all_2.js @@ -1,5 +1,6 @@ var searchData= [ ['defaultlocale',['defaultLocale',['../struct_n_v_g_s_d_k___highlight_config_params.html#a7f4f852d4fe97048f20dcdcc401ab82b',1,'NVGSDK_HighlightConfigParams']]], - ['destroyhighlights',['destroyHighlights',['../struct_n_v_g_s_d_k___highlight_close_group_params.html#a3d7eae61163c4616a42569ca8d7785c6',1,'NVGSDK_HighlightCloseGroupParams']]] + ['destroyhighlights',['destroyHighlights',['../struct_n_v_g_s_d_k___highlight_close_group_params.html#a3d7eae61163c4616a42569ca8d7785c6',1,'NVGSDK_HighlightCloseGroupParams']]], + ['development_20guide',['Development Guide',['../index.html',1,'']]] ]; diff --git a/doc/html/search/all_9.js b/doc/html/search/all_9.js index 1518243..1da4ac4 100644 --- a/doc/html/search/all_9.js +++ b/doc/html/search/all_9.js @@ -1,6 +1,5 @@ var searchData= [ - ['overview',['Overview',['../index.html',1,'']]], ['open',['open',['../struct_n_v_g_s_d_k___overlay_state_changed_notification.html#ad9684c86b575f710bcc784942e6bf256',1,'NVGSDK_OverlayStateChangedNotification']]], ['opengroupasync',['OpenGroupAsync',['../class_gfe_s_d_k_1_1_highlights.html#ab1b35bd4fe9e8aac357db3aeabfefa1b',1,'GfeSDK::Highlights::OpenGroupAsync()'],['../class_gfe_s_d_k_1_1_highlights_impl.html#a8420e07f1812fba8bf961e90e5795d3b',1,'GfeSDK::HighlightsImpl::OpenGroupAsync()']]], ['opensummaryasync',['OpenSummaryAsync',['../class_gfe_s_d_k_1_1_highlights.html#a9d1ab59542571efe90391aea1503411b',1,'GfeSDK::Highlights::OpenSummaryAsync()'],['../class_gfe_s_d_k_1_1_highlights_impl.html#ab31f1319b9dcf33cf9146916f8a1d5f3',1,'GfeSDK::HighlightsImpl::OpenSummaryAsync()']]], diff --git a/doc/html/search/pages_1.js b/doc/html/search/pages_1.js index 277cca0..8ccb486 100644 --- a/doc/html/search/pages_1.js +++ b/doc/html/search/pages_1.js @@ -1,4 +1,4 @@ var searchData= [ - ['overview',['Overview',['../index.html',1,'']]] + ['development_20guide',['Development Guide',['../index.html',1,'']]] ]; diff --git a/doc/html/search/searchdata.js b/doc/html/search/searchdata.js index 9dbaa1a..78cf9fe 100644 --- a/doc/html/search/searchdata.js +++ b/doc/html/search/searchdata.js @@ -8,7 +8,7 @@ var indexSectionsWithContent = 5: "n", 6: "n", 7: "n", - 8: "co" + 8: "cd" }; var indexSectionNames = -- cgit v1.2.3