This is mainly aimed at the developers. Would an option to enable logging to internal database/clipboard or memory device be helpful in tracking down and dealing with bugs? Thus the less technical inclined can turn on logging, recreate the error and mail in the log. Worth pursuing?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's already a limited capability for logging. It's only a compile time flag, because I think making decisions about whether to log on each logging statement at runtime would be too slow. However we could post a separately compiled version which logging enabled.
Anyway, there currently aren't enough logging calls spread around in code to make it all that useful for general purposes at the moment. I use it to track down specific errors by sprinkling temporary logging statements around where I think problems might be.
I suppose I could try to guess where problems might occur at some point and put logging around there, but that's not something I consider high priority at the moment.
What I might start doing for problems I can't replicate (such as device specific issues), is to put a bunch of temporary logging calls around where I think the problem might be, compile that, send it to the bug reporters, and get the logs from them. Would obviously require a slight additional time commitment from those users, and might be somewhat slow to resolve problems. What do you think about that general approach?
I'm also considering making releases with an version that has some options tweaked which makes the player about 4% faster, but reduces error checking and does some other things I don't want to do for the main release. Do you think this would be worth doing?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is mainly aimed at the developers. Would an option to enable logging to internal database/clipboard or memory device be helpful in tracking down and dealing with bugs? Thus the less technical inclined can turn on logging, recreate the error and mail in the log. Worth pursuing?
There's already a limited capability for logging. It's only a compile time flag, because I think making decisions about whether to log on each logging statement at runtime would be too slow. However we could post a separately compiled version which logging enabled.
Anyway, there currently aren't enough logging calls spread around in code to make it all that useful for general purposes at the moment. I use it to track down specific errors by sprinkling temporary logging statements around where I think problems might be.
I suppose I could try to guess where problems might occur at some point and put logging around there, but that's not something I consider high priority at the moment.
What I might start doing for problems I can't replicate (such as device specific issues), is to put a bunch of temporary logging calls around where I think the problem might be, compile that, send it to the bug reporters, and get the logs from them. Would obviously require a slight additional time commitment from those users, and might be somewhat slow to resolve problems. What do you think about that general approach?
I'm also considering making releases with an version that has some options tweaked which makes the player about 4% faster, but reduces error checking and does some other things I don't want to do for the main release. Do you think this would be worth doing?