RDP development thread

[HatCat]

Yeah, angrylion credited me for fixing that algorithm.

He replaced all those excessive branching algorithms with this static sign-extension macro I wrote:

/*
 * Standard hardware sign-extension operations:
 */
#define SIGN8(x)        ((signed char)(x))
#define SIGN16(x)       ((INT16)(signed short)(x))

/*
 * Virtual register sign-extensions and clamps using b-bit immediates:
 */
#define CLAMP(i, b)     (i & ~(~0x00000000 << b))
#define SB(i, b)        (i &  ( 0x00000001 << (b - 1)))
#define SE(i, b)        (i | -SB(i, b))

/*
 * Forces to clamp immediate bit width AND sign-extend virtual register:
 */
#define SIGN(i, b)      (SE(CLAMP(i, b), b))

Originally Posted by MarathonMan

1) angrylion optimized it fairly heavily... for the P4 architecture when compiled on MSVC. So that means no vectorization, lots of awkward help-the-P4-and-try-to-manually-unroll-everything, etc.

Jesus, the guy sure knows how to use the INLINE and FORCEINLINE features, on almost every single function, wouldn't you say?
EDIT: While claiming that his code is all ANSI C.

He never could understand what I was talking about, about slightly sacrificing some over-exerted optimization, in exchange for lower program size and smaller cache usage, for long-term optimization. He relied too much on his benchmark profiler's IMMEDIATE results of fewer or less seconds.

I think mudlord's main point was that he refused to use SSE intrinsics to pump it up.

angrylion's a dedicated guy and whatnot, but I really think he's awfully pessimistic/uncreative/depressive about trying to bypass the limits of his thinking. Pretty much every optimization he's done is too much dependent thinking. It should be more optimistic than that, sometimes more intuitive, but no, he has to rely on instant benchmark reports which are only correct for the present, not necessarily the future.

[mudlord_]

http://www.sendspace.com/file/i9etxg

up to date compile of angrylion's stuff. I used the mylittle-nocomment branch.

[HatCat]

Looks straight in sync with it.

If you get to making more updates to this from his original code, the first thing I would do is change the window resolution from 1024x768.

Tried to tell him that if the VI DAC native resolution is about 640x480, he should just use that for the window screen size, not the size of my monitor screen / 1024x768. Can't even see the whole screen on this monitor because of his retarded choice. All he had to say was, "I don't care. Compile it yourself." (Somehow magically forgetting that I've had it compiled for months, or else wouldn't have corrected so much of his code.)

I know I'm being an egotistical/critical ass sometimes, but 1024x768 window size?
I should invent a TV screen 4x3 pixels, or something smaller than VI native res, just to troll him.

[GPDP]

Can't an option to resize the window be added?

[HatCat]

If I had a clue what I was doing with this type of process, I think I'd rather not.

I would add an option to use DP-native resolution (auto-resize the window to non-pixilated, RDRAM-sized literal resolution display), VI-native resolution (detected 640x480 for NTSC, something else for PAL), and as far as custom resolutions, I would just add a full screen mode so that if the user wanted any other resolution, they could change their monitor desktop screen size to that.

Technically the only *real* resolution with a pixel-accurate RDP emulator is the VI one, based on angrylion's explanations. Anything else is just scaling and interpolating it to a larger screen or distorted aspect ratio. So that's why I'd rather take advantage of full screen mode implementation to handle "custom" resolutions.

[GPDP]

Now, this is but my own personal view, but I don't like using fullscreen for emulation, and I find that solution to be really roundabout. Not to mention depending on the monitor for interpolation tends to not have the best results, at least in my experience. I think having built-in scaling options to be the superior alternative, but of course, I can't code worth a damn, or I'd do it myself. All I can do is give my own perspective.

[HatCat]

And it's a matter of my perspective also.

I figure that if people think the screen is too small for their comfort, they use full screen so they can relax, kick back without having to look at a window from far away.

I also figure that if people think the screen is too big, pixilated, interpolated, or they're trying to work with other processes in the background and monitor things up close to their desktop/keyboard, that they want the minimum possible "accurate" resolution (which in this case is not quite as high as the VI native resolution necessarily).

Also, it wouldn't be "depending on the monitor for interpolation" exactly, because the default would be to use the VI-native resolution which is larger than the RDP one in most cases, so there would unconditionally be interpolation with or without full screen, unless the DP-native res from the RDRAM literal bytes span per pixel was forced.

But, you're probably right anyway. Maybe some people find excuses for needing fixed, custom resolutions, like 999x666, or 101x1010101. I guess I sometimes just feel like coding for simplicity, and cutting out potentially extraneous features that shouldn't have an use. Because I think of anything between full-screen max and accurate min, except 640x??? VI res, to be pretty much inconsistent and redundant, for accuracy purposes.

[shunyuan]

Originally Posted by haxatax

I was also young and niave at the time, though that justn't justify things.
I find it weird you had to bring up something...6 years ago.

That is not the only case, what about your modified version of RiceVideo plugin?

Although for this modification, you only strip out the OpenGL driver and static link with BMGLib, but you didn't release the source code till now and put your name on this plugin.

I named your name out not to justify things, I just want to point out when you said me kill the N64 emulation, an emulation criminal, but you seem to forget what you have done. And you have two standards, one for yourself, one for me. When you insult me or criticize me, one finger pointed to me, four fingers pointed to yourself.

[shunyuan]

Originally Posted by MarathonMan

suanyuan, am I supposed to just trust that you don't look at my code when we're optimizing? It seems unfair that my changes are out in the public for viewing, while your's are not, if we're trying to have a friendly competition here....

I write plugin for fun and to improve my programming skills, and I don't plan to port your code to my fork although it is a trivial task. I just curious how fast your SSE optimized build will boost for angrylion's nocomment build since you also bypass the VI filter. I will keep my build to v1.5 as reference.

[mudlord_]

Fair point, I killed emulation 7 years ago.

I must be drawn and quartered, I won't deny it.