All changes are relatively minor. Completely backward compatible to v0.6. Added examples on how to create basic Open Automate proxy executables.
This is the first public release of the OpenAutomate SDK. It is completely backward compatible with v0.6. All changes are relatively minor.
The version number has been incremented to 1.0-1, but backward compatibility is maintained. In the future, major version number changes (e.g. v2.0) will mean backward compatibility is not maintained.
We found a variety of cases where the test suite in v0.6 didn't catch conformance problems. A variety of new tests have been added to ensure these issues are found early by the application developer.
The license has been changed, now that OpenAutomate is public. The new license was written with the idea that all developers--commercial or open source--can feel free to integrate OpenAutomate into their applications freely, without being encumbered by any licensing issues related to redistribution.
Please see the LICENSE file included with the SDK for more information.
oatest has a new command-line options for listing available test modules, and choosing which specific modules should run. Run oatest with the -h option for a complete list of options.
This release helps maintain backward compatibility in future releases by adding the byte size of structs passed to functions in the API to the structs themselves. Unfortunately, this addition breaks backward compatibility with previous versions of the OpenAutomate SDK.
The SDK now includes the OpenAutomate conformance test suite named oatest in source form. Applications that claim to be OpenAutomate compatible must pass the tests within this suite. Please see the "oatest" document for more information.
oaMessage, oaNamedOption, oaOptionDependency, and oaCommand now have a field oaInt StructSize as their first field. This is initialized to the sizeof() of their respective types in order to allow either backward compatibility in future versions of the SDK or graceful failure.
The StructSize field must be initialized by the associated oaInitXXX() functions:
/* Initializes an oaMessage */
void oaInitMessage(oaMessage *message);
/* Initializes an oaCommand */
void oaInitCommand(oaCommand *command);
/* Initializes an oaNamedOption, and the member oaOptionDependency */
void oaInitOption(oaNamedOption *option);
oaInitCommand() was added to the API. It must be called on the oaCommand object sent to oaGetNextCommand() before each call to oaGetNextCommand().
Until this release, plug-ins had to infer the type of oaOptionDependency.ComparisonVal by maintaining a mapping of option names to option type from previous calls to oaAddOption. This had two unfortunate side-effects:
The addition of ComparisonValType removes these restrictions. The application must now set this value to the type of the parent option. It must match the type of the parent option, when oaAddOption is called with it.
This function should be used to initialize an oaiFunctionTable instead of explicitly calling memset() and setting the TableSize field.
Note: This function is only used when developing OA plug-ins.
Many locations where oaString were used have now been switched to const oaChar * to force compile time restrictions in cases where the string should not be modified.
Fifth alpha release. This is mostly "service pack" release intended to ease OA integration
It eliminates the need to change project options or change OpenAutomate sources
OpenAutomate should compile without warnings when default warning level is used.
It was decided OpenAutomateUtil is not essential part of the core OpenAutomate and may be separated from the core OpenAutomate logic.
simple_app.cpp now enumerates options using namespaces new options added to provide more relevant examples of options usage
OpenAutomate.h:
- OA_PLATFORM (old PLATFORM may cause collisions) is "autodetected"
OpenAutomate.cpp:
- init string parsing modifications
- Unicode fix (LoadLibraryA is replaced with LoadLibraryW)
- minor bugfixes
Fourth alpha release.
From the docs:
All of the OpenAutomate functions that receive or return strings are assumed to be UTF-8 encoded strings. This simplifies plug-in development, while still supporting all languages. Furthermore, it maintains compatibility with standard ASCII strings without any extra effort.
This function may be used for providing per frame statistics and results during benchmark runs. It works similarly to oaAddResultValue() but is called every frame, before oaDisplayFrame() is called.
From the docs:
This command instructs the application to run as normal; it should run as if OpenAutomate mode was never invoked. However, when the user chooses to exit the application, the application must not exit the process. Instead, it should cleanup and return back to the command loop, calling B.
This is a general mechanism for the application to signal the plug-in with various events. Currently, the only supported signal is for rebooting the system in the middle of a benchmark run. See the documentation for more information.
All OpenAutomate compatible apps are required to register themselves within the system during installation, in order to allow for quick identification of the applications existence.
See the "Registering an Application with OpenAutomate" section of the "README" document for more information>.
Also, see OpenAutomateUtil.h and OpenAutomateUtil.c for functions on registering, unregistering, and finding OpenAutomate enabled applications.
Note: The Win32 registry is not supported by the utility functions in this release.
In addition, OpenAutomateUtil.h and OpenAutomateUtil.c were added to the SDK. These files are not strictly required for OpenAutomate compatibility, but are made available to users of the SDK to use as they see fit.
Currently, it the only functions included are ones related to application registration.
Options can now be enumerated by the application in a hierarchical fashion similar to files and directories.
The special namespace User/ must be used to differentiate between options directly visible to the end-user, and ones that aren't. See the "Registering an Application with OpenAutomate" section of the "README" document for more information.
Third alpha release.
OpenAutomate is now the official name for the harness.
All function and type prefixes are changed from sash to oa.
Enum value prefixes are changed from SASH_ to OA.
The -sash command-line option is now -openautomate.
All other references to SASH are changed to OpenAutomate.
Second alpha release.
Can optionally be called at the end of a benchmark run, to communicate result values such as benchmark scores, tests passing/failing, etc...
The prototype for sashAddOptionValue() has changed from:
void sashAddOptionValue(const SASH_CHAR *name, const sashValue *value);
to:
void sashAddOptionValue(const SASH_CHAR *name,
sashOptionDataType value_type,
const sashValue *value);
Previously, addition of new functions to the SASH API required recompilation of plug-ins to be compatible with apps that use the new API. This is no longer necessary.
This matches the new sashAddResultValue(). Previously, the type of the value parameter was implicitely defined by the application through the SASH_CMD_GET_ALL_OPTIONS command. The requirement to issue this command first is no longer needed. Furthermore, the conformance test can now check for consistency between the types in SASH_CMD_GET_ALL_OPTIONS and SASH_GET_CURRENT_OPTIONS.
Can now be built on POSIX compatible OSs (e.g. Linux, Cygwin, ...). note hasn't be tested extensively, and unicode support is not robust yet.
A GNUmakefile has been added, for building on these OSs.
First alpha release.
NVIDIA® GameWorks™ Documentation Rev. 1.0.220830 ©2014-2022. NVIDIA Corporation and affiliates. All Rights Reserved.