you probably meant:
+ return ((this)->*(TexelFetch[index % 79]))(s, t, tbase, tpal, userdata);
of course yeah, I meant that, but it was late and I pressed Shift+6 (&) on my Italian EEEPC keyboard instead of Shift+5 (%).
Anyway, it seems that having made a mistake in 1943.c (admittedly very stupid) and having 0 understanding of multithreading (which lead me to post a couple of noobish-level messages on forums) automatically labeled me as plainly stupid, as others' replies seem to suggest... for the record I'm not :P
It's corrupted memory, I guarantee it, so any of amount of finagling it into working is just going to mask the issue, not make it more apparent.
people can't understand the basics of masking probably shouldn't even be allowed access to the MAME / MESS code.
however, as others pointed out, the problem lies elsewhere, i.e. why does the index get larger than 79 in the first place? And why do the masks contain values larger than 0x0f
did any of you read my message?
I did not think there was space for misunderstandings.
I have written "the crash is due to out of bound accesses" which can be fixed by those changes (with %79), in the sense that the crash does not happen anymore when those bounds are enforced and therefore it proves in my eyes that those specific calls are the culprit. period.
I have added that it is obvious it is not a fix because of the several glitches produced as a byproduct (which I noticed because I was looking for further out of bounds calls). having svn access I would have added the code to the repository if I had thought it was a fix, wouldn't I?
otoh, I have never suggested JD nor any other devs to add such masking in the code, I just pointed out which functions ended up with out of bounds values (which I thought it could be of use) and I cannot even understand why I'm wasting this time to explain...
