Thanks TomToad.
I've been giving this a lot of thought over the past few days and I think the standard/your way is probably what I will have to do. Not necessarily because it's how I want it to work but because there really isn't any other way to do it. I ideally want to have global variables which you call with the same variable name but which actually pull up different contents depending on what thread you're in - and the only way to do that is to add a layer of abstraction and some kind of index or custom types.
I will also look at using "AllocThreadData(), GetThreadData(), and SetThreadData()" to store the custom thread type instance as real thread-local-storage, because then I don't have to pass it to *every* function, only the ones that need it which can go get it on a per-function basis. Real thread-local storage is basically storage that you request from the operating system to be associated with the thread that is running the code accessing it, basically like using Local variables but without any context restrictions other than that it's part of the thread - and you don't seem to need to know any `ID` of the thread you're running in order to assign the storage or use it.
I also think I'm going to store what used to by my globals as fields in the custom thread type. I did some speed tests of using single dimensional arrays vs multi dimensional vs custom types accessing fields and they are quite similar with types being a bit faster most of the time.
I've been giving this a lot of thought over the past few days and I think the standard/your way is probably what I will have to do. Not necessarily because it's how I want it to work but because there really isn't any other way to do it. I ideally want to have global variables which you call with the same variable name but which actually pull up different contents depending on what thread you're in - and the only way to do that is to add a layer of abstraction and some kind of index or custom types.
I will also look at using "AllocThreadData(), GetThreadData(), and SetThreadData()" to store the custom thread type instance as real thread-local-storage, because then I don't have to pass it to *every* function, only the ones that need it which can go get it on a per-function basis. Real thread-local storage is basically storage that you request from the operating system to be associated with the thread that is running the code accessing it, basically like using Local variables but without any context restrictions other than that it's part of the thread - and you don't seem to need to know any `ID` of the thread you're running in order to assign the storage or use it.
I also think I'm going to store what used to by my globals as fields in the custom thread type. I did some speed tests of using single dimensional arrays vs multi dimensional vs custom types accessing fields and they are quite similar with types being a bit faster most of the time.