Previous Thread
Next Thread
Print Thread
Page 12 of 15 1 2 10 11 12 13 14 15
Joined: May 2009
Posts: 2,023
Likes: 59
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,023
Likes: 59
Originally Posted By Haze
nothing wrong with *safer* code in general


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.

Joined: Mar 2001
Posts: 16,892
Likes: 51
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,892
Likes: 51
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.

Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
Originally Posted By Darkstar
you probably meant:
Code:
+	return ((this)->*(TexelFetch[index % 79]))(s, t, tbase, tpal, userdata);

grin


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

Originally Posted By Just Desserts
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.


Originally Posted By Haze
people can't understand the basics of masking probably shouldn't even be allowed access to the MAME / MESS code.


Originally Posted By Darkstar

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

Joined: May 2009
Posts: 2,023
Likes: 59
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,023
Likes: 59
Originally Posted By etabeta78
specific calls are the culprit


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.

Joined: Feb 2010
Posts: 71
M
Member
Offline
Member
M
Joined: Feb 2010
Posts: 71
Originally Posted By etabeta78
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 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.

Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
well, you are right I have misused the word culprit and call (probably part of the misunderstanding wink ).
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.

Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
Originally Posted By Matty
Also, %79 doesn't do what you want, anyway


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 wink ) so that next time I check if my brain is correctly plugged-in before posting such embarrassing things...

Joined: Feb 2004
Posts: 2,344
Likes: 61
Very Senior Member
Online Content
Very Senior Member
Joined: Feb 2004
Posts: 2,344
Likes: 61
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!

Joined: Feb 2012
Posts: 5
M
Member
Offline
Member
M
Joined: Feb 2012
Posts: 5
Originally Posted By Haze
people are bothering you more because you're working on it... same with anything really.

and having testers while you're actively working on code tends to be good, you can't be expected to catch everything which changes for every change you make, so it can be a handy indication as to if you're doing things right.

simple as that ;-)

actually you should probably be impressed, considering 100% performance is still out of reach with current CPU speeds it's impressive people are testing the driver enough to give you reports :-)


Ain't that the truth wink
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.

Joined: May 2009
Posts: 2,023
Likes: 59
J
Very Senior Member
OP Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,023
Likes: 59
Originally Posted By mudlord
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! smile

Page 12 of 15 1 2 10 11 12 13 14 15

Link Copied to Clipboard
Who's Online Now
3 members (Lord Nightmare, Colin Howell, Dullaron), 18 guests, and 1 robot.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,070
Posts118,930
Members5,014
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com