#281  
Old 21st June 2013, 01:54 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Thumbs up

Quote:
Originally Posted by angrylion View Post
You obviously failed to read my quote from DirectX 8 SDK help files. I'll repost it once again just for you: "RECT structures are defined so that the right and bottom members are exclusive—therefore, right minus left equals the width of the rectangle, not 1 less than the width".
Thanks, you are right about the DirectDraw bit function.
__________________
---------------------
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
  #282  
Old 21st June 2013, 02: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

Quote:
Originally Posted by suanyuan View Post
Thanks, you are right about the DirectDraw bit function.
I look at it this way.

Believe everything I read?
Or believe everything I see?

If God help me I would have to pick one, I would pick the latter.

And believing Microsoft's documentation doesn't solve every problem.
It was causing that stupid blur.

If suanyuan's change really is just a sacrifice then hell, need a better API.
Reply With Quote
  #283  
Old 21st June 2013, 02:34 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
If suanyuan's change really is just a sacrifice then hell, need a better API.
You just need a better operating system.
Reply With Quote
  #284  
Old 21st June 2013, 02:38 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

probably lol

I've been meaning to jump Linux off my USB drive for a while now.

Of course I won't be able to test this plugin on it because DirectDraw doesn't specifically work on Linux without some stupid virtual overhead.

I suppose portability is yet another one of the many things that isn't on this guy's list of virtues for the RDP emulator.
But that's alright, considering he sure made accuracy one of them.

I just need enough experience to rewrite it back.
Reply With Quote
  #285  
Old 21st June 2013, 02:57 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
I look at it this way.

Believe everything I read?
Or believe everything I see?

If God help me I would have to pick one, I would pick the latter.

And believing Microsoft's documentation doesn't solve every problem.
It was causing that stupid blur.

If suanyuan's change really is just a sacrifice then hell, need a better API.
For mario64, the picture actually shrink down from 640x237 (anti alias by VI) to 320x240, the interpolation (blur) is done by the display driver.

The modification that I made is trying to shrink down the picture from 639x237 to 320x240 and accidentally get rid of blur (a hacky way to get rid the blur).

Anyway, it is not a bug or angrylion's RDP, nor an error of DirectX SDK documents.
__________________
---------------------
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
  #286  
Old 21st June 2013, 03:00 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

uhh...640x237 / 639x237, meaning, the native resolution which is down-scaled to 320x240?

oh christ. I guess I really shouldn't have hijacked that section of rdp_update.
What a mess. Why would Mario have a resolution of 640x237

*staying tuned for the next episode of RestoreOldCode and study it to find out*
Reply With Quote
  #287  
Old 21st June 2013, 03:11 PM
dsx_ dsx_ is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2010
Location: Australia
Posts: 1,105
Default

i thought PAL was 720x576
Reply With Quote
  #288  
Old 21st June 2013, 03:13 PM
angrylion angrylion is offline
Member
 
Join Date: Oct 2008
Location: Moscow, Russia
Posts: 36
Default

Quote:
Originally Posted by FatCat View Post
You said "offset in RDRAM bytes between successive lines" when we were talking about VI_WIDTH_REG.

Now you're saying that pixels in each VI line are "independent to VI_WIDTH_REG".
You know very well I didn't say that, fatpimp. I said that the amount of pixels copied from the RDRAM on each VI line had nothing to do with VI_WIDTH_REG. VI_WIDTH_REG, however, is an offset or delta between starting positions of successive lines copied from the RDRAM, but these starting positions do not necessarily change (advance) at the start of each and every subsequent VI line. These starting positions can also differ by x * VI_WIDTH_REG between consequent VI lines, where x is a positive integer. This is all kind of encoded in this formula that I posted: VI_ORIGIN_REG + (line_in_VI_coordinate_space * y_add + y_start) * (VI_WIDTH_REG & 0xfff), which you failed to look at with any degree of attention.

Quote:
Originally Posted by FatCat View Post
Does this mean pixels are not copied from RDRAM?
What a funny joke, ha ha. Except not at all.

Quote:
Originally Posted by FatCat View Post
Paradox.
You answer a claim to bias with a measurement of one particular TV you know.

Not every TV is 4:3, not every game uses 4:3, and not every TV is 1024x768.
You just want to put a label of bias on everything that does not follow your hackish method that effectively skips a part of the VI called "VI interpolation filter" (by ignoring the fact that the dimensions of VI coordinate space are constant). As for games, they all use the same resolution, the resolution at which the VI feeds their RGB bytes to the video DAC.

Quote:
Originally Posted by FatCat View Post
Why would I want to do that? My fork already resizes the window to smallest native resolution (or so attempts).
Your fork resizes to some arbitrary RDP-dependent resolution, which has nothing to do with the VI hardware, so I fail to see how could anyone call this resolution "native".

Quote:
Originally Posted by FatCat View Post
If I want to do a sprite rip of a character and make a PNG/GIF out of it, am I going to take a screenshot of the game on your [accurately on the hardware] stretched and possibly distorted DirectDraw render?

No, I am going to request an active availability to see the software-accurate native render of the screen in native resolution where possible so that my sprite rip I make is accurate.

It is not an option with your original code, and I don't need it to be because I have it implemented in my fork. :P
The smarter way, however, is to rip it directly from the RDRAM or TMEM. I think you actually emulate the VI to some extent, and VI filters can distort your beloved sprite greatly just because it is surrounded by some pixels with unfavorable coverage values, let alone in cases when a certain VI dithering mode is activated.

Quote:
Originally Posted by FatCat View Post
Lowering your forced resolution from 1024x768 is equally as pointless as it being fixed to any particular resolution in the first place.
If I make it 640x480 I'm basically following your example, except with a smaller screen.
I can just as well claim that your RDP-controlled resolution changes are forced and pointless. But leaving your beloved labels aside, I guess no one in their right mind could raise any objections against these resolution changes having nothing to do with the real hardware's behavior.

Quote:
Originally Posted by FatCat View Post
When I said "I hope your advice helps" I meant the advice you gave me earlier about using the two SYNC registers and, some other thing, for deriving the native resolution on the video interface.
I've already posted the native resolutions of the visible portion of the video interface coordinate space: it's either 640x480 or 640x525. You can lower them a bit to simulate TV's overscan areas. If you want to artificially raise them to make them directly deducible from two SYNC regs just to enjoy thicker black borders surrounding your visible area, while still having constant, unchanging screen resolution, feel free to pursue this "achievement".
640x480 or 640x525 is the resolution of the RECT from which I blit into my 1024x768 window. To avoid this final pass of interpolation, it's enough to make a window the same size as that RECT.

Quote:
Originally Posted by FatCat View Post
It was causing that stupid blur.
A random bug in your GPU driver was causing the fixated blur.
Reply With Quote
  #289  
Old 21st June 2013, 03:19 PM
shunyuan's Avatar
shunyuan shunyuan is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2013
Posts: 491
Default

Quote:
Originally Posted by FatCat View Post
uhh...640x237 / 639x237, meaning, the native resolution which is down-scaled to 320x240?

oh christ. I guess I really shouldn't have hijacked that section of rdp_update.
What a mess. Why would Mario have a resolution of 640x237

*staying tuned for the next episode of RestoreOldCode and study it to find out*
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.

For mario64 the resolution in color frame buffer is 320x237. If you dump the pixels in frame buffer with this resolution to a bitmap it won't have any distortion.

For VI interface, the gamma correction, color dither, bin-linear filter can use D3D or OGL to replace software image process (just like what has done in MAME display driver).
__________________
---------------------
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
  #290  
Old 21st June 2013, 03:45 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

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.

For mario64 the resolution in color frame buffer is 320x237. If you dump the pixels in frame buffer with this resolution to a bitmap it won't have any distortion.

For VI interface, the gamma correction, color dither, bin-linear filter can use D3D or OGL to replace software image process (just like what has done in MAME display driver).
Definitely. That's what I've been doing.
This is exactly what I mean about not distorting the screen.

I already know angrylion's way of doing it is accurate because he correctly emulates the upscaling in the N64 Video Interface DAC output, but it's just more natural to by default let the screen be at the native vi dac resolution like you said. See, somebody is capable of admitting this.

We are not switching between TV screens here. We are free of the limitations of a fixed screen output because we are using an emulator, so I recommend taking advantage of that. It's no more accurate, but it's no less either.

And LOL at angrylion's "fatpimp" reply, I'm almost flattered.
I just thought he was acting angry for amusement/learning; I didn't know he was actually pissed off at us the entire time.

wait, maybe that's supposed to be

IDK, it can flip back and forth.
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 12:29 AM.


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