#321  
Old 24th June 2013, 08:57 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

I never did learn what "berating" means.
*rubs the fat in his belly*
*crystal ball effect in the shininess of his fat reveals it's a negative thing*

But yeah, I have a more immutable (and I think readable) solution to the mess of nested expressions used in some of the formula calculation for RDP_UPDATE (UpdateScreen).

Code:
EXPORT void CALL UpdateScreen(void)
{
    CCVG *viaa_cache, *viaa_cache_next, *divot_cache, *divot_cache_next;
    CCVG viaa_array[2048];
    CCVG divot_array[2048];
    UINT32 final = 0;
    register int i, j;
    // register float scale_x; should not have FP
    // register float scale_y; should not be float
    const int x1      = (*gfx.VI_H_START_REG >> 16) & 0x01FF;
    const int h_start = x1 - (ispal ? 128 : 108);
    const int h_end   = (*gfx.VI_H_START_REG >>  0) & 0x01FF; /* x2 */
    const int v_start = (*gfx.VI_V_START_REG >> 16) & 0x01FF; /* y1 */
    const int v_end   = (*gfx.VI_V_START_REG >>  0) & 0x01FF; /* y2 */
    const int delta_x = h_end - x1; /* abs(x2 - x1) */
    const int delta_y = v_end - v_start; /* abs(y2 - y1) */
    const int hres = delta_x >> 0;
    const int vres = delta_y >> 1;

... (still in progress)
Reply With Quote
  #322  
Old 24th June 2013, 10:48 PM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

Quote:
Originally Posted by FatCat View Post
But yeah, I have a more immutable (and I think readable) solution to the mess of nested expressions used in some of the formula calculation for RDP_UPDATE (UpdateScreen).
It's only called 60 times a second.
Reply With Quote
  #323  
Old 24th June 2013, 11:03 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

something like that, lol

This is not meant to be an efficiency change.
I cross-copied too much stuff that I took notes off the Glide64 etc. sources.

I'm re-reading the RCP memory map and angrylion's original source to fix mistranslations of his master branch into my fork (which to my knowledge, are only in this very function...any other part of n64video.cpp I have more-or-less copied word-for-word exactly as he wrote it to avoid problems.)

So the purpose of this rewrite isn't premature optimization.
It's to help me understand RDP functions better by rewriting it in my preferred syntax (which certainly he himself may or may not agree with) and hopefully to make the code more flexible.

I don't like, for example, having to paste the same expression over and over.
That's why I define the immutable constants for the compiler to induce their calculation timings at compile-time.
Reply With Quote
  #324  
Old 25th June 2013, 12:04 AM
angrylion angrylion is offline
Member
 
Join Date: Oct 2008
Location: Moscow, Russia
Posts: 36
Default

Quote:
Originally Posted by suanyuan View Post
I prefer to define the native resolution to be the resolution of color frame buffer. Because it is the right resolution to interpret the pixels in color frame buffer.
Yeah, what a great definition, except it's hardly "native", since the VI knows nothing about any of (theoretically countless) RDP's frame buffers. The VI can copy pixels from any address in the RDRAM and ignore all of the RDP's frame buffers and their sizes and settings. The VI can just as well copy pixels written by the CPU without any intervention by the RDP, when the RDP was basically inactive. If the RDP rendered nothing and everything that appears on the screen was written by the CPU, how would you define a "native resolution"? In this case you have no choice but to derive this "native resolution" from VI_X_SCALE_REG, VI_H_VIDEO_REG and their vertical counterparts. But the VI may select/copy only each second, each third, etc. pixel among the pixels that are successive in the RDRAM. So you'll compute your "native resolution", but the pixels that comprise the rectangle of this size will be discontinuous in the RDRAM, separated by many invisible pixels. So how is that "native"?

Quote:
Originally Posted by FatCat View Post
And LOL at angrylion's "fatpimp" reply, I'm almost flattered.
I'm not sure why you're surprised or rather pretend to be surprised. You repeatedly addressed me by distorted renditions of my nickname: "Mr. Lion Sir" and "angrypimp", completely unprovoked. Now you're apparently trying to ascribe some uncontrollable fits of anger to me.

Quote:
Originally Posted by FatCat View Post
If you honestly think I was trolling you this entire time I think you should think again.
...
I did not mistakenly quote you in those excerpts.
I copied and pasted exactly what you wrote.

If you think I "know very well you did not say that" then I think your judgement is severely blinded by your anger problems as copy/paste rarely lies about what was said.
No, you mistakenly quoted me and you pasted what I've not written. Quoting your post #281: "Now you're saying that pixels in each VI line are "independent to VI_WIDTH_REG"". I haven't said that. I said that the amount of pixels copied on each VI line is independent of VI_WIDTH_REG. Pixels themselves can be described as dependent on VI_WIDTH_REG, in the sense that VI_WIDTH_REG influences their addresses in the RDRAM. The amount of pixels copied is another matter, it is independent of VI_WIDTH_REG. You've also changed the preposition I originally used from "of" to "to" in your misquotation. Sure, it's not a disastrous misquotation, yet you used it to demonstrate how there's some alleged contradiction in my explanations.

Quote:
Originally Posted by FatCat View Post
Not copied at all?

Why did you say this then--

Originally written by you:
"To simplify what's happening, for each VI line, the VI copies an amount of pixels,"

You think I just used the word "copy" for no apparent reason?
Your original question "Does this mean pixels are not copied from RDRAM?" did not follow from anything I've written in this thread about the VI, because by then I had posted more than once about how the VI copies/reads pixels from the RDRAM. I'm not sure what contradictions you had managed to find in my posts on this subject. In fact, your question "Does this mean pixels are not copied from RDRAM?" seemed so wild that I couldn't decide if it was a joke or trolling. For no reason I assumed it was a joke. So I added "Except not at all", which meant in the context of my response, no, I don't think that this joke was funny, not at all.

Quote:
Originally Posted by FatCat View Post
I see now that I entirely misunderstood your meaning of the "native resolution".

You're saying that the native DAC RGB resolution to the N64 OS VI, is generally 640x480 NTSC, for all games, never changes.

(By the way, if that's true, that makes me wonder even more why you prefer 1024x768 over 640x480, but like you said, you don't care, so I guess I shouldn't ask you and make you mad again.)
Yeah, I've already said this twice, I explicitly called 640x480 a "native resolution of the visible area of VI coordinate space". And I said that this native resolution was constant.
Your question about my decision to upscale the image to 1024x768 seems very strange to me. When people launch a NES emulator, why do they ever use a resolution higher than 256x224? How dare these idiotic villains maximize or stretch their emulator windows arbitrarily? What right do they have to add an additional pass of (possibly bilinear) filtering in the process? Is this your line of thought? In my opinion, they are not some evil conspirators. Their desktop resolutions are for some reason much higher than 256x224, so they want to reduce the strain on their eyes and see details of the image with ease. It is exactly for this reason that I upscale the image to 1024x768 to suit my personal tastes and my personal desktop resolution. Everybody is able to create a window of other dimensions by changing just two global variables in my code.

Quote:
Originally Posted by FatCat View Post
The 320x240 or 320x237 resolution is correct to show all of the pixels not doubled or quadrupled in size, so I'm looking for a general formula that will let me derive resolutions like that for games (if I don't already have it...).
Yeah, very good, but I can't help you with this. I'm not interested, because I know that the real VI does nothing like this, it actually quadruples pixels, as you put it. You could probably use VI_X_SCALE_REG, VI_H_VIDEO_REG and their vertical friends to deduce the dimensions that you want.

Quote:
Originally Posted by FatCat View Post
Or do you somehow have proof that their API just doesn't suck? Simple.

Your GPU had the problem just as much as mine did.
DirectDraw undefined scaling operations, the unpredictability of downsizing a 639x237 screen or w/e the hell.

You could have just sent me a screenshot of my plugin where there was NOT any blur, but maybe you don't have access to this sort of GPU?
Maybe you just won't admit that directx sucks. :P
Technically, there was no violation of the standard on either GPU, because DirectDraw does not define texture interpolation methods. What you call "blur" is probably just bilinear filtering. I don't see any "problem" with this "blur". The inconsistent or fixated blur is, however, a visual problem in both your and my eyes, that's why I allowed myself to call it a driver bug, although technically it's not a real driver bug.

Quote:
Originally Posted by FatCat View Post
My latter method is preferable, but the compiler cannot possibly guess this for you if it doesn't know whether file[i].format was predetermined or forced to a 2-bit value in each other function.
format has 3 meaningful bits and can equal 4. Omitting & 3 just breaks texturing for tiles of "intensity-only" format, unless you rewrite main switches in fetch_texel_entlut() and fetch_texel_entlut_quadro(). This omission of & 3 breaks texturing regardless of your using ADD or XOR. With & 3 included your code is not faster than mine. format being a 3-bit variable is evident both from my code and from the docs.
Reply With Quote
  #325  
Old 25th June 2013, 12:53 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by angrylion View Post
format has 3 meaningful bits and can equal 4. Omitting & 3 just breaks texturing for tiles of "intensity-only" format, unless you rewrite main switches in fetch_texel_entlut() and fetch_texel_entlut_quadro(). This omission of & 3 breaks texturing regardless of your using ADD or XOR. With & 3 included your code is not faster than mine. format being a 3-bit variable is evident both from my code and from the docs.
I was wondering about that, which is why I commented out the "& 3" because I wasn't sure.
I don't think it was as self-evident as you said, but I'm sure it's documented and I'm sure that if I did a Find/Search elsewhere in the code I would have arrived at your conclusion eventually. I was already optimistic enough about preferring bit-wise over arithmetic as a general rule of thumb.

So yes, saying ((x ^ 2) & 3) is hardly faster than ((x + 2) & 3), or at least the same speed.
However, it is simpler/consistent (adheres to bitwise rather than fusing arithmetic with bit-wise) and forward-extendable into the algorithm case that only 2 bits were significant (if for other cases, you would no longer have to say & 3, then just say x ^ 2 and it's faster).

But no longer a good enough change to argue about you not merging it in.

Quote:
Originally Posted by angrylion View Post
I'm not sure why you're surprised or rather pretend to be surprised. You repeatedly addressed me by distorted renditions of my nickname: "Mr. Lion Sir" and "angrypimp", completely unprovoked. Now you're apparently trying to ascribe some uncontrollable fits of anger to me.
At the same time, I'm not going to blame you for not understanding this, but I don't see what's so offensive about "Mr. Lion, sir".
"Sir" here more often than not is used as a respectful suffix in civilized conversation.

I totally didn't mind it when you called me "Dr. Cat" in your answer. I thought that was cute XD

Maybe the "angrypimp" thing was offensive.
Then again by that token I thought "angrylion" itself, your original name, could have been nearly as much of a potential insult. I guess I assumed from your name that, you only playfully called yourself angry and wouldn't react at a joke.

But yeah, I've been known to screw around with other peoples' usernames and poke fun at them from time to time for the lulz, sorry about that I guess. It's not just you I do that with, I just don't usually get that reaction.

Quote:
Originally Posted by angrylion View Post
No, you mistakenly quoted me and you pasted what I've not written. Quoting your post #281: "Now you're saying that pixels in each VI line are "independent to VI_WIDTH_REG"". I haven't said that. [...]
Look, I don't have the mental concentration to go back and analyze everything, but I did double-check your posts, and the part in-between the quotation marks "quote goes here" was in fact a character-by-character, exact ASCII copy-paste of your posts.

Maybe somewhere along the line it's possible I misconstrued it with an interpretation outside of the quoted message, but at the same time, I don't see why you would think it even likely that I've pasted "what you've not written".

Anyway, never mind I don't really care to analyze it any longer.
It seemed as though you may have contradicted yourself but maybe people have different teacher acquaintances.

Quote:
Originally Posted by angrylion View Post
Your question about my decision to upscale the image to 1024x768 seems very strange to me. When people launch a NES emulator, why do they ever use a resolution higher than 256x224? How dare these idiotic villains maximize or stretch their emulator windows arbitrarily? What right do they have to add an additional pass of (possibly bilinear) filtering in the process? Is this your line of thought?
First, I just thought from your disagreements with my choice of (self-adjusting) screen resolution, and how you opposed my idea of not using the VI native screen size instead, meant you were more than particular about using a fixed resolution than I was. And if so, why you'd prefer fixed 1024x768 over fixed 640x480.

Second, your reason for preferring 1024x768 is fine to me. I don't see it as evil conspirator-ness or the like.
However, I do consider 640x480 to be a "compatibility default" for a plugin that would let you change the resolution yourself later.
Because for system compatibility, it is better to assume the worst-case scenario with user monitors. They could have even worse than me: a 640x480 monitor.

Compatibility defaults would always default to the smallest, accurate resolution (which I suppose could be nothing less than 640x480), and it should be emphasized to the user that they can change it to whatever they like.

Anyway, it's not an important detail since few other people use the plugin other than yourself (or am I wrong), so it would be equally as merited to keep the current size.
Reply With Quote
  #326  
Old 25th June 2013, 01:02 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Oh, and just to add.

In case you were wondering,
OMG Y didn't this guy compile it without "& 3" to see it for himself that the texturing would have broken.

Because I was 30% through a manual merge of your r75, and it was not the best time to pause my merge by temporarily losing the line number or adding in premature, untested speed hacks or compiling them.

So as a reminder to come back to it later, I posted it here in this thread in case other people had comments about the strategy. I still prefer the bit-wise method even though you have to say & 3, but I was never expecting that to be your reaction.

I was just busy merging, and that's a tedious and annoying job task I put at the top of my list of things to be done with.
Reply With Quote
  #327  
Old 25th June 2013, 01:10 AM
MarathonMan's Avatar
MarathonMan MarathonMan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Jan 2013
Posts: 454
Default

http://i.imgur.com/kp8te.gif
Reply With Quote
  #328  
Old 25th June 2013, 01:24 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by MarathonMan View Post
http://i0.kym-cdn.com/photos/images/...49_1584652.gif
Reply With Quote
  #329  
Old 25th June 2013, 02:39 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Also, yet another one of the things I have a hard time reading from this plugin's source:

Code:
#ifdef WIN32
    int slowbright = 0;
    if (GetAsyncKeyState(0x91))
        brightness = (brightness + 1) & 15;
    slowbright = brightness >> 1;
#endif
I can't guess how this is supposed to function accurately on the RDP as this would be Win32-specific code.

You have `slowbright` used nowhere else in your RDP UPDATE function except just near the end:

Code:
#ifdef RENDER_MAX_CVG_ONLY
	if (cur_cvg != 7)
		r = g = b = 0;
	else
		r = g = b = 0xff;
#endif
	adjust_brightness(&r, &g, &b, slowbright);
	d[i] = (r << 16) | (g << 8) | b;
	x_start += x_add;
}
So what could this possibly mean for Linux?
The RDP is accurately emulated X method on Win32, Y=undefined method for any other OS where `slowbright` doesn't get declared, let alone initialized?

As such, this build would fail on any other system (never minding that DirectDraw is not portable, but, if you love the added blur, you love the added blur...um I prefer pixel-accuracy tho :/ guess I was under the wrong impression that was what this plugin strived for).

You would do well to avoid this hazardous style of code if you would abide by the real C regulations and never declared variables in the middle of the function space.
New variable names like "slowbright" should be named at the function name space at the top above the function body with everything else, not in the middle scattered away from everything else.

IMO, I think it's foolish that C++/C99 allowed for this habit.
Scattering variable introductions just isn't organized.
Separate code from data, like you would do in asm.
Reply With Quote
  #330  
Old 25th June 2013, 03:20 AM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

rewrite this part of code
Code:
#ifdef WIN32
    int slowbright = 0;
    if (GetAsyncKeyState(0x91))
        brightness = (brightness + 1) & 15;
    slowbright = brightness >> 1;
#endif
to
Code:
#ifdef WIN32
    int slowbright = 0;
    if (GetAsyncKeyState(0x91))
        brightness = (brightness + 1) & 15;
    slowbright = brightness >> 1;
#else
    int slowbright = brightness >> 1;
#endif
should solve your problem.
__________________
---------------------
CPU: Intel U7300 1.3 GHz
GPU: Mobile Intel 4 Series (on board)
AUDIO: Realtek HD Audio (on board)
RAM: 4 GB
OS: Windows 7 - 32 bit
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 10:48 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.