Home Page Forums MAME MAME N64 Discussion Station

One could validly argue that code that's in the middle of a core render loop that gets called four times for every on-screen pixel probably should be written to be fast and correct, not safe.

Like I said, you need an #ifdef that drops a megaton of asserts on the N64 renderer to catch bad values immediately when they originate.

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




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...

But they aren't. The calls don't do anything other than access data that's already screwed up because the memory is already trashed when going into it. That's like saying the guy who gives CPR to a corpse is responsible for killing the guy.

I hope this is an issue with language barrier, because if it isn't, you're digging a whole for yourself. Those are not "calls" - they are array accesses. They are not the "culprit" for any definition of the word. The fact that they crash is a symptom. The culprit causing out-of-bound accesses is probably miles away. This is what I jokingly call "forensic debugging" at work. You can easily see that things aren't as they should be, but the trick is working backwards to discover what got them into that state. It isn't easy.

Also, %79 doesn't do what you want, anyway: that produces a number in the range 0..78 so attempting to access the last element in the array would wrap around to the first. You want %80 if anything, but as everyone has already mentioned, it's an expensive non-fix for an issue elsewhere. Treating the symptom doesn't cure the disease.

well, you are right I have misused the word culprit and call (probably part of the misunderstanding ).
still my original thought was that you could find useful to know that among the hundreds of involved parameters it was the mask_s and mask_t values to be trashed on MacOSX after a couple of frames (respectively one between format/size/en_tlut/tlut_type), e.g. so that you add the fatalerrors suggested by Arbee only to the routines that can affect those quantities and not everywhere.

but apparently my idea was naive and it is not so useful as I hoped. fair enough.

I give up. it's not my day and I have a brand new super stupid post to add to my pedigree. I have to check what I had written in the code I was testing last night (to see how stupid I have been), but already not spotting that I was posting %79 instead of %80 in two occasions (last night and this morning), is more than enough to justify any attack directed to me since last night: I deserved them all :P

EDIT: ok, my self esteem is partially safe: the code I tested did not contain %79, but %80, so I don't need to hide my head in a brown paper bag.

Anyway, this does not change at all the fact I had not realized in two separate occurrences I was posting the wrong mask on a public forum, so please keep bashing me a bit more (maybe explaining me how to do operations with two digits, since my fingers are not enough ) so that next time I check if my brain is correctly plugged-in before posting such embarrassing things...

Hey, taking the bit about not having enough fingers to do two digits seriously for a moment Koreans have an awesome way of counting from zero to 99 on your fingers: http://en.wikipedia.org/wiki/Chisanbop Definitely worth learning!

Ain't that the truth
Speaking of performance, MG and I made some intriguing discoveries with the current threading in the RDP rendering. Seems with N64 emulation, diminishing returns are done with more than 5 cores.

Like for instance, average of 59% of Mario 64's attract loop on a AMD Phenom II x6 1055T versus around 80% on a non Sandy Bridge Intel i7.

Or it could be AMD just sucks at emulation.

A little of column A, a little of column B. That sort of performance is known about with regard to MAME's threaded polygon renderer, I just wasn't sure if it would apply in this case given that the threads have more work to do than the Voodoo rasterizer in MAME, which I would have thought would help keep the main CPU thread from getting starved of work to dispatch, but I guess not!