|
 |
User changes. yuqk / v4. Options re-work status.
The current output related option(s):
declare=<name>= <float or string> value only
become(s):
+-ub_ user_bool_filename= string value only
+-ui_ user_int_filename= string value only
+-uf_ user_flt_filename= string value only
+-us_ user_str_filename= string value only
+-uv2f_ user_vec2d_filename= string value only
+-uv3f_ user_vec3d_filename= string value only
+-uv4f_ user_vec4d_filename= string value only
+-uv5f_ user_vec5d_filename= string value only
+-um_ user_matrix_filename= string value only
Add set of standard user boolean switch names.
+-uof_00 user_on_off_00= on|off
+-ux_ user_execute_filename= string value only
(Thought is to let users create user input files
with whatever scripting, programming language
they wish during options parsing)
Only the rough outline above. No integrated code. (I have a couple
standalone test file parsing programs running)
I'll mention here, one of the aims of these option updates is to make
nearly all (all?) option settings available via new inbuilt functions in
the parser(*). An option name string being passed as the query key. In
limited testing this works, but I've not implemented / tried the vectors
or matrix stuff above. Those will need more code to truly be integrated
during parsing.
The overall thinking is to implement something more powerful than
'declare=...'.
The filenames used would be space delimited and use ascii-string(fast)
(or maybe std::string utf8) keys. The same inbuilt functions used as
option settings at parse time would be used to access these values by
key(**), while new inbuilt functions would be required to support vector
/ matrix input (or direct use?).
Aside: Values set with these user files would be guaranteed, top level,
read only, 'globals'. There are outstanding issues with the v3.8 global
dictionary implementation that I've never gotten sorted. (I believe the
local dictionary implementation in V3.8 is OK / clean.)
Bill P.
(*) - The declare feature identifiers, image_width, image_height and
maybe a half dozen more 'apparent keywords' are, internally, unprotected
identifiers. This is an opening for difficult SDL bugs. This said, I
don't plan to delete these 'apparent keywords' any time soon. I do plan
to remove the declare option.
(**) - Yes, need sanity checking to be sure users don't try to set
'option strings' via any of these user input files...
Post a reply to this message
|
 |