SoftGraphic graphic plugin

[HatCat]

Originally Posted by angrylion

I don't care if it was better or worse with one CPU core or another, because it has nothing to do with the RDP and it has everything to do with the CPU.

Obviously, but in your words:
"It definitely couldn't render levels correctly with Ziggy's MAME SDL port,"
It didn't sound like you were talking about the CPU that time.

It sounded like you were challenging my maintenance of upgrades to the SDL version of the plugin that, even with the correct CPU, allegedly could not have sharply rendered the game. :S

You weren't clear with your meaning that time.

Originally Posted by angrylion

There are no special build parameters. I link it in MSVC 2002 with ddraw.lib and dxguid.lib from DX8 SDK. So the cause of the fixated blur is either a bug in your GPU drivers, or your code changes, or some post-XP changes to the Windows implementation of DirectDraw, or some errors in MinGW versions of these two static libraries.

I think I'll let you be the judge of that.
But, only if you're interested -- As you should have gotten a private message on this forum.

I sent you a PM with a link to my MinGW build of your mylittle-nocomment r73 DirectDraw code.
If you try this plugin tell me if you get any of the obvious blur that I do on, say, the Super Mario 64 File Select screen:



The words on the right half of the screen are obviously blurred.
Those on the left are not.

[HatCat]

By the way, Mr. Lion sir I am very curious.

As I've just investigated with the SDL version of my plugin.

If what you said about the CPU core being fault was entirely, 100% true,

Then I wonder how come Indy Jones START menu screen looks like this:

... in SDL old version of the plugin I was maintaining,

yet in r73 of your current DirectDraw code, it stays a black screen:


I'm using the same exact CPU (interpreter, PJ64 1.6) settings when I changed between the plugins, so how is it the CPU's fault this time?

If that intrigues you I guess I can send you a private link to the SDL plugin I have been working as well.

[angrylion]

Originally Posted by FatCat

It didn't sound like you were talking about the CPU that time.

It sounded like you were challenging my maintenance of upgrades to the SDL version of the plugin that, even with the correct CPU, allegedly could not have sharply rendered the game. :S

While it might be possible to interpret my phrase in this way, from the context of the conversation, it's more likely that I only challenged your allegation that my RDP changes introduced some new bug, which wasn't present in your SDL plugin. It was also only natural for me to assume that you made your comparison using the same emulator and RSP pluign. So my phrase only referred to the inability of your SDL plugin to render the game any better on the same broken CPU core.

Here's how the binary you sent me looks in my Windows XP + ATI R300.

[HatCat]

Originally Posted by angrylion

Here's how the binary you sent me looks in my Windows XP + ATI R300.

That looks like the ENTIRE screen is blurred.

If you look at my screenshot, at least the left half of it is pixel-sharp.

No wonder you weren't able to see what I was trying to say before.
On your end, the pixels are consistent (but I think blurred).
It doesn't help that your native plugin just stretches the window to 1024x768 instead of just letting you see the game screen at native resolution either.

And the SDL version of RDP plugin looks even better than that:


Never minding that shit around the text "MONO", JPG compression, etc. ... but it looks sharper.

I think maybe DirectDraw is responsible for scaled distortion of at least sections of the screen. Why not break away from Micro-shit and use SDL, or at least Windows GDI to remove hardware-dependent variations on render output?

Originally Posted by angrylion

While it might be possible to interpret my phrase in this way, from the context of the conversation, it's more likely that I only challenged your allegation that my RDP changes introduced some new bug, which wasn't present in your SDL plugin. It was also only natural for me to assume that you made your comparison using the same emulator and RSP pluign. So my phrase only referred to the inability of your SDL plugin to render the game any better on the same broken CPU core.

As I said at the beginning of my post, I believed you already.
The CPU for pj64 1.6 obviously caused texture crashes.
I only told you it worked on my SDL plugin because, in fact, it did, but apparently on some other CPU core.

However as you can see in my above post, maybe as it turns out, the CPU was not everything...

Now, I need to go to bed now.
I can argue about the rest of this in the morning.

[shunyuan]

Originally Posted by FatCat

The words on the right half of the screen are obviously blurred.
Those on the left are not.

I have figure out this bug, function RomOpen() at main.cpp


chage

src.right = PRESCALE_WIDTH;

to

src.right = PRESCALE_WIDTH - 1;

EXPORT void CALL RomOpen(void)
{
       .............	
	src.top = src.left = 0; 
	src.bottom = 0;
	src.right = PRESCALE_WIDTH - 1;

	rdp_init();
}

[shunyuan]

Originally Posted by FatCat

Then I wonder how come Indy Jones START menu screen looks like this:

... in SDL old version of the plugin I was maintaining,

Do you think the main menu of "Star Wars - Rogue Squadron" is the same issue?

Because I remember I have seen the main menu of "Star Wars - Rogue Squadron" rendered with your SDL version of RDP.

[HatCat]

Originally Posted by suanyuan

I have figure out this bug, function RomOpen() at main.cpp


chage

src.right = PRESCALE_WIDTH;

to

src.right = PRESCALE_WIDTH - 1;

EXPORT void CALL RomOpen(void)
{
       .............	
	src.top = src.left = 0; 
	src.bottom = 0;
	src.right = PRESCALE_WIDTH - 1;

	rdp_init();
}

oh hell, that's right, you tried saying something like that already
I just couldn't understand it before

I'll try to adopt that change tomorrow morning, thanx

[angrylion]

Originally Posted by FatCat

I'm using the same exact CPU (interpreter, PJ64 1.6) settings when I changed between the plugins, so how is it the CPU's fault this time?

If that intrigues you I guess I can send you a private link to the SDL plugin I have been working as well.

No, Dr. Cat, it does not intrigue me in the least, because the title screen shows in 1964 0.8.4/0.8.5, so not showing it in PJ64 1.6 is most likely an accuracy improvement, because my plugin processes whatever broken RDP commands the emulator sends to it more properly.

Originally Posted by FatCat

It doesn't help that your native plugin just stretches the window to 1024x768 instead of just letting you see the game screen at native resolution either.

There's no "native resolution", except for the resolution of the VI coordinate space, and your plugin doesn't use it either. The VI feeds RGB values to the Video DAC at VI's own resolution. Remember, the VI knows nothing about what the RDP draws.

UPDATE: OK, I've checked Indiana Jones and Rogue Squadron, and both games stopped showing their start screens in Project64 1.5/1.6 when I made the VI use its native VI_WIDTH_REG register rather than RDP's fb_width (as it did in MESS 0.128) register as a measure of lines' width. Both games still show their start screens fine in 1964. So, indeed, it was an accuracy improvement on my part and exposed a CPU inaccuracy in Project 64, which was masked until then.

UPDATE 2: I'm very happy that this change

src.right = PRESCALE_WIDTH - 1;

allows your GPU driver to avoid inconsistent filtering and give you the picture that you want (not that I consider it accurate or inaccurate, because methods of texture filtering when doing scaled blits are undefined in DirectDraw). However, your change actually contradicts DirectDraw documentation by Microsoft. Specifically, when discussing IDirectDrawSurface7::Blt method, it says "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". So the "bug" you, suanyuan discovered is not a bug in my code, it's a bug of your GPU driver.

[HatCat]

Originally Posted by angrylion

UPDATE: OK, I've checked Indiana Jones and Rogue Squadron, and both games stopped showing their start screens in Project64 1.5/1.6 when I made the VI use its native VI_WIDTH_REG register rather than RDP's fb_width (as it did in MESS 0.128) register as a measure of lines' width. Both games still show their start screens fine in 1964. So, indeed, it was an accuracy improvement on my part and exposed a CPU inaccuracy in Project 64, which was masked until then.

Sounds good.
*Dr. Cat scratches his fat belly, confuzzled as to why other cat has t3h angry m4dz*

Are you saying that (VI_WIDTH_REG & 0x00000FFF) is always the correct width of the VI?

(If so, I think you could benefit more by using zilmar's `void ViWidthChanged()` to update any VI_WIDTH_REG-related things. Whether or not you decide to put any non-dummy code in this function, the plugin spec is going to wastefully call this function regardless whenever this value gets changed, so if I were you I'd make use of it.)

And you're saying there is no "native resolution" of the RDP, only the VI res?

...

Originally Posted by angrylion

There's no "native resolution", except for the resolution of the VI coordinate space, and your plugin doesn't use it either. The VI feeds RGB values to the Video DAC at VI's own resolution. Remember, the VI knows nothing about what the RDP draws.

...
Then why is it that, if there's only one "native resolution" and it's the VI one, the screen ends up stretched or the pixels are stretched to fit the window, in cases where VI_WIDTH does not match calculated fb_width?

EXPORT void CALL UpdateScreen(void)
{
    register int i, j;
    register float scale_x;
    register float scale_y;
    UINT32 final = 0;
// ... stuff
/* cxd4 -- Divide off redundant checks using ViWidthChanged() timer input ? */
    if (sync == TRUE)
    {
        scale_x = (float)(vi_x_scale & 0x00000FFF) / 1024.f;
        scale_y = (float)(vi_y_scale & 0x00000FFF) / 1024.f;
        scale_x *= (float)(hres);
        scale_y *= (float)(vres);
        if ((old_width != (int)(scale_x)) | (old_height != (int)(scale_y)))
        {
            if ((hres <= 0) | (vres <= 0))
                goto NEXT;//fatalerror("lolwut");
            if (scale_x*scale_y == 0.0f)
                fatalerror("lolnut");//goto NEXT;
            old_width  = (int)(scale_x);
            old_height = (int)(scale_y);
            ChangeWinSize(old_width, old_height);
            sync = FALSE;
        }
    }
NEXT:
    INT32 h_end = hres + h_start;
    INT32 hrightblank = PRESCALE_WIDTH - h_end;
// ... remaining stuff
}

This is my code I added on how I re-size the emulator window and its game screen actively while the game is running (using a global int `sync` updated by ViWidthChanged as a message that other VI registers like scale xy are about to be changed + screen size possibly).

Since (sync) is rarely true, it saves executing this code a lot of times that UpdateScreen is called, whereas on your plugin it executes constantly even when there was no change to scale_x or scale_y since the last procedural call, but also, I'm not quite at 90% sure, that my method is updating them frequently enough.

Even Jabo's LLE plugin agreed that emulated width/height of some games was 640x480 screen size, but your updates seem to just use a constant ratio all the time?! Anytime the screen is drawn at 640x480 it's pixilated for any game!
Like it's really double what it should be!
Yet, for those games, VI_WIDTH_REG itself was set to 640 pixels wide.
So wut? You would rather just draw everything in 1024x768 all the time then show any possibility of a non-stretched, base raster size where base pixel dimensions aren't multiplied?

Because different games seem to have different ways of doing this.
Especially when you disable/enable 8 MB RDRAM memory expansion, sometimes what the old SDL version drew was twice the width (thus enhanced hi-res N64 gfx) than when game was using 4 MB.
Unless you're saying only one exact resolution or aspect ratio is possible every time, surely you must have a bug with just stretching it out to 1024x768 all the time.

[HatCat]

Originally Posted by suanyuan

I have figure out this bug, function RomOpen() at main.cpp


chage

src.right = PRESCALE_WIDTH;

to

src.right = PRESCALE_WIDTH - 1;

EXPORT void CALL RomOpen(void)
{
       .............	
	src.top = src.left = 0; 
	src.bottom = 0;
	src.right = PRESCALE_WIDTH - 1;

	rdp_init();
}

Hm, there appears to be a lost row of pixels in the Score screen:


Up at the "Bob-omb Battlefield" line, you can see a missing row of pixels.

The coin next to " x 11" isn't the same as all the other coins below it.
The 3 stars on that row aren't the same (as tall) as all stars below it.
Other pixels on that row are similarly lost.