I suggest to turn off logging by default and turn on by pressing button (F8 at this time, if I remeber correctly). Why - to better control what need to log, for example you need to log during gameplay and you do not want log all before that.
Also need to make GUI indication - for example - create string "Logging" near FPS counter and make it inactive (grey) when logging disabled. When enabled - black.
If destination(Console or TextFile) of log is not set - grey, and pressing F8 does nothing.
I have a better solution which I will be implementing after the v0.1 stable release: Configurable log levels.
My ideas is to do the following:
@LukeUsher some logs are only dumped on debug builds (e.g.: kernel function's name and arguments). Should also those be made available on release builds and on the GUI with the above method?
In Dxbx these log levels were dynamic. In Cxbx-Reloaded, it'd be nice to be able to start out with only a subset, and extend that during specific (testing) phases at runtime too
In Dxbx these log levels were dynamic.
"boolean" MayLog function:
https://github.com/PatrickvL/Dxbx/blob/82d2c21b7bebaf57690f614efdc2414865be27e6/Source/Delphi/src/uLog.pas#L276-L283
Prefix log values:
https://github.com/PatrickvL/Dxbx/blob/82d2c21b7bebaf57690f614efdc2414865be27e6/Source/Delphi/src/uLog.pas#L74-L98
I think Dxbx using this method has more limitation.
For Module, I think we can use enum for it as index usage. Then we can perform something like this.
// logList provide unlimit ability to add more module filter
// module_index is an enum type "NV2A, DSND, D3D8, KRNL, etc
// log_level (maybe enum) for LOGLEVEL_INFO, LOGLEVEL_WARN, etc
if (logList[module_index] & log_level) {
//if true, allow log it here.
//module_str[module_index]
}
We might need to use macro to generate two tables for module, one for enum type and other as string.
I noticed that LOG_XBOX_CALL, LOG_FIRST_XBOX_CALL and LOG_ONCE are never used anywhere in the code, can they be removed entirely then?
They come from my WIP Less vertex Patching branch, which never got merged. There's still lots of stuff in there that could be useful, so no harm in keeping those macros for now if you ask me
I noticed the request for logging off. In my opinion, logging should remain on since anything can happen at very early boot which may not be able catch after late key press for turn logging on. However, pull request #1395 also preserved user's request to either keep on or off through multi-xbe boots.
Most helpful comment
I have a better solution which I will be implementing after the v0.1 stable release: Configurable log levels.
My ideas is to do the following: