[$threadinfo[title]]

[Dave2001]

Gugaman and I have spent a long time trying to fix the remenants of our resolution problem.

I understand that the VI_X_SCALE_REG and VI_Y_SCALE_REG are both 1/scale up factor as 2.10, but these values don't appear to be all there is to scaling...

For example, the scaling values for mario are not 1.0, 1.0 as you would expect, but rather:
x_scale: 2.000000, y_scale: 1.000000

ALSO, the Capcom logo screen from Megaman 64 needs to be scaled by 0.5, 0.5. However, the scaling values for this are:
x_scale: 1.000000, y_scale: 1.000000

How can this be possible? The y scale value for both mario and megaman is the same for both, when one needs to be scaled and the other not?

The only explanation for that I can find is that something else has an effect on scale that we haven't found yet... Anyone have experience with this?

[Hacktarux]

Dunno if you have changed this since the 0.1 release but you have to use the VI_WIDTH_REG to know the actual resolution of the n64. (Can't understand what the SCALE_REGs do exactly)

[Dave2001]

We have looked deeply into VI_WIDTH_REG also...

If VI_WIDTH_REG is width, what is height? 3/4*VI_WIDTH_REG?

Anyway, all of our tests with VI_WIDTH_REG weren't very successful either, so if it is important, how does it fit in with the scale values?

[Hacktarux]

On a NTSC rom height is 3/4*VI_WIDTH_REG
and on a PAL rom height is 9/11*VI_WIDTH_REG (but it has to be scaled then to fit on a PC monitor)

I will try to look at megaman 64 to see if i understand what is your problem....

[StrmnNrmn]

Are you using the VI_H_START_REG and VI_V_START_REG registers? This is the current code from daedalus - it seems to work pretty well for all the roms I've tested - both pal and ntsc.


u32 dwScaleX = *g_GraphicsInfo.xVI_X_SCALE_REG & 0xFFF;
u32 dwScaleY = *g_GraphicsInfo.xVI_Y_SCALE_REG & 0xFFF;

f32 fScaleX = (float)dwScaleX / (1<<10);
f32 fScaleY = (float)dwScaleY / (1<<10);

u32 dwHStartReg = *g_GraphicsInfo.xVI_H_START_REG;
u32 dwVStartReg = *g_GraphicsInfo.xVI_V_START_REG;

u32 hstart = dwHStartReg >> 16;
u32 hend = dwHStartReg & 0xffff;
//DBGConsole_Msg( 0, "h start/end %d %d", hstart, hend ); // 128 725 - 597

u32 vstart = dwVStartReg >> 16;
u32 vend = dwVStartReg & 0xffff;
//DBGConsole_Msg( 0, "v start/end %d %d", vstart, vend ); // 56 501 - 445

mViWidth = (hend-hstart) * fScaleX;
mViHeight = ((vend-vstart)/2) * fScaleY; // /2 is because vertical is measured in half-lines

[Gugaman]

when should we refresh it?
at VI_Status_Changed() ?
seems not enough...

and... seems to me i dont need vi_width_reg to calc the X scale, but i need it to the Y scale. i think there's something missing yet

[StrmnNrmn]

I just check it at the start of each display list - that way you're sure the scaling is correct each time. It can't change during the course of the display list executing, so there aren't any problems doing it this was as far as I can see.

[Gugaman]

yeah. i was going to post exactly this...

still some games arent working like megaman capcom logo and duke nukem zero hour menu, but now dave woke up and we'll burn our brains again :)

[Dave2001]

I have gotten the following values from games:

// DN:ZH, y 2x (2 times too large)
// size: 320x474, real: 320x240

// Megaman, x 2x, y 2x
// size: 640x237, real: 1280x960

// Goldeneye, x somewhat large, y somewhat large
// size: 440x325, real: 440x330

// Lode-runner, y 2x
// size: 320x474, real: 640x480

The first value is the mViWidth x mViHeight, and the second is (*gfx.VI_WIDTH_REG) and 0.75 * (*gfx.VI_WIDTH_REG). All are (U) games.

The problem is... there doesn't seem to be a final equation that fits everything and comes up with a good scale value...

[Dave2001]

Another interesting thing... I've grouped all of the games by their problem, and all the ones except the 1280x960 ones seem to be able to be scaled by the first value! But why don't aren't 1280x960 ones the same? The y on this resolution seems to be divided by two.

// Mario, perfect
// size: 320x237, real: 320x240


// x 1.sthx too large, y ok
// Mortal Kombat 4: x too large
// size: 400x237, real: 400,300


// x ok, y 2x too large
// Lode-runner, y 2x
// size: 320x474, real: 640x480

// DN:ZH, y 2x
// size: 320x474, real: 320x240


// x 1.sthx too large, x 1.sthx too large
// Goldeneye, x somewhat large, y somewhat large
// size: 440x325, real: 440x330


// x 2x too large, y 2x too large
// Megaman, x 2x, y 2x
// size: 640x237, real: 1280x960

// Donkey Kong 64: x 2x, y 2x
// size: 640x237 real: 1280x960

[Dave2001]

By just doing a special case for 1280 and multiplying height by two, ALL of the games on that list were fixed. I'm sending it to my testers to see the results of other things...

[LD.]

Good luck :)

[Dave2001]

Amazing... not a single problem reported...

I guess this is good enough then! :) And I have also included different scaling for PAL games.

[Dave2001]

WHOA!!!!!

Yesterday the Gentleman had asked me to put in some values into the Glide64.ini to scale banjo kazooie and also banjo-tooie to the correct size. I did, and it had some slight problems, so i took it out while Gugaman and I worked on this resolution problem.

Well, now that the resolution problem is done, I put the scale values back in and run Banjo Kazooie. The screen was way too large. Then I think, this is weird... the values worked before. Then I decide to take the values out again and look where the screen is positioned, and...

It's perfectly centered and scaled to the screen! The resolution fix also fixed banjo kazooie :D

(and I also assume Banjo-Tooie as well as the Gentleman said it had similar problems)

I really thought that this problem was caused by something else and not the scale value since most other things with the scaling problem were way too large instead of too small.