Finding Native N64 Screen Resolution

[HatCat]

Does anybody know of a proper way to derive the current native resolution for drawing the N64 screen?

I'm currently using the way used in zilmar's CFB plugin.
Fetch RDP VI_WIDTH_REG on ViWidthChanged.
Assume a 4:3 game aspect ratio (not always true), so height = 3/4 * width.


The past few weeks, my plugin has been crashing Resident Evil 2, Gauntlet Legends, and eventually in-game, Indiana Jones and the Infernal Machine.
I figured out it was caused by attempting to blit SDL pixels to a screen size smaller than what the game was intending to allocate.

For example, Resident Evil 2 crashes when I say use 4:3 game ratio like zilmar's CFB.
That causes 436x327 resolution.
But when I say 1:1 ratio, or force it to 436x436 (640x480 also worked), RE2 goes in-game and doesn't crash.

I can boot Gauntlet Legends with the RDRAM 4MB expansion pak emulated, but not without emulating it cause the native resolution gets changed out of bounds.
That was why Project64 2.0 was giving the N64Class RunRSP error.

So how should I derive proper, non-4:3 native N64 ratios...
...by listening to the wisdom of others?
or by eventually finding alternative controls in perhaps the other VI registers and experimenting myself?

[dsx_]

the only way i know is by change the emulated width and height settings in jabo's plugin until the screen looks right and then remember the values, but thats probably not the answer you were after xD

[HatCat]

Though I appreciate your answer it is not.

That usually works; the trick is that windowed resolutions in most plugin configs (including Jabo's) are (I think? correct me if I'm wrong) usually just 4:3 resolutions like 320x240, 640x480, 512x384, w/e: width/height = 4/3 = 1.333...

It doesn't let you pick *all* (if any) of the special widescreen resolutions certain games will use with or maybe even without the 8MB RAM.
So it's difficult to fetch the exact screen resolution for special games.

zilmar's method works only for most of the 4:3 games.
I want to resize the window and force the resolution to the native resolution, since it seems as if SDL cannot stretch the screen to fit the emulator window like Glide64/Jabo/Rice/most plugins can for some reason....

I need a programmatic way of deriving the exact native resolution off the VI/RDP registers, if possible.
Or I could just say 1024x768 to fix the crashing, but window usually too big, and the game screen's never stretched.

[dsx_]

Originally Posted by FatCat

That usually works; the trick is that windowed resolutions in most plugin configs (including Jabo's) are (I think? correct me if I'm wrong) usually just 4:3 resolutions like 320x240, 640x480, 512x384, w/e: width/height = 4/3 = 1.333...

yeah the only 16:9 resolution in jabo d3d8 is 1024x576; theres also 1380x768 but thats 16:8.9 (why??? idk)

when i said emulated width and emulated height i meant the manually adjustable settings in the ROM settings tab of jabo's config where you type in a number (this doesnt resize the window though)

[HatCat]

Originally Posted by dsx!

when i said emulated width and emulated height i meant the manually adjustable settings in the ROM settings tab of jabo's config where you type in a number (this doesnt resize the window though)

Heh, duh..forgot about that.
It's been years since I did that for Rogue Squadron, I typed in loads of different values for the menu and got 512xsomething, it was a 16:9 resolution I think, I did the pre-algebra and it approximated the correct pixel for me to the simple ratio.

There is a setting like that in rice video too but who cares

Originally Posted by dsx!

yeah the only 16:9 resolution in jabo d3d8 is 1024x576; theres also 1380x768 but thats 16:8.9 (why??? idk)

Precisely part of the problem.
1380:768 = 690:384 = 345:192 = 115:64 = LOLWUT

It could be that a game uses weird ratios.
With my current 4:3 assumption, games using different ratios might draw pixels to the screen, sailing off the edge of the window.
Thus, crash in the software rasterizer for writing to out-of-screen pixels.

So Gauntlet Legends in 8 MB looks like this:


Window is too big, but as usual SDL cannot upscale/resize native screen drawings, so the actual screen is perfectly sized within the window.
But if it goes outside the window!
On SDL, crash on TMEM R/W (something like that).

Currently trying to reverse patterns in the VI registers to see if it will approximate a pattern for the native w/h for me.

[HatCat]

dgfdfgdfgdf old post enough linking to it!
Sorry but fairly sure it doesn't have to do with Hacktarux's problem.

I'd talk a little more about what does if I could even post on EmuTalk. On the other hand, it'd also be somewhat more convenient if Hacktarux checked his e-mail more often.

[HatCat]

found a little somesthing in Glide64 as well--

http://code.google.com/p/glidehqplus....cpp?r=282#226

void _ChangeSize ()
{
...
    wxUint32 scale_x = *gfx.VI_X_SCALE_REG & 0xFFF;
    if (!scale_x) return;
    wxUint32 scale_y = *gfx.VI_Y_SCALE_REG & 0xFFF;
    if (!scale_y) return;

    float fscale_x = (float)scale_x / 1024.0f;
    float fscale_y = (float)scale_y / 2048.0f;

    wxUint32 dwHStartReg = *gfx.VI_H_START_REG;
    wxUint32 dwVStartReg = *gfx.VI_V_START_REG;

    wxUint32 hstart = dwHStartReg >> 16;
    wxUint32 hend = dwHStartReg & 0xFFFF;

    // dunno... but sometimes this happens
    if (hend == hstart) hend = (int)(*gfx.VI_WIDTH_REG / fscale_x);

    wxUint32 vstart = dwVStartReg >> 16;
    wxUint32 vend = dwVStartReg & 0xFFFF;

    rdp.vi_width = (hend - hstart) * fscale_x;
    rdp.vi_height = (vend - vstart) * fscale_y * 1.0126582f;
    float aspect = (settings.adjust_aspect && (fscale_y > fscale_x) && (rdp.vi_width > rdp.vi_height)) ? fscale_x/fscale_y : 1.0f;
... (rest of the source in that function isn't relevant)

I wonder if this can be converted into a standard formula....

It's not possible from the get-go, of course.
Since judging by the above results, initialized resolutions leave most of the registers of the VI blank. This suggests zilmar's plugin system is either not updating them in time, or that there is a delay until a later phase until game-resolution-relevant bits are set.

After all, the plugin spec does not mean you must show all the updated VI registers of the new resolution, just notify as soon as VI_WIDTH_REG was changed.
So hm, it may be possible...

[mudlord_]

http://code.google.com/p/angrylions-...t/n64video.cpp

[HatCat]

Originally Posted by FatCat

Virtual Chess 64 changed mid-game to 640x480 on ViWidthChanged to 640:

VI_STATUS_REG:          0000311E // 12574 [dec]
VI_ORIGIN_REG:          00000A00 // 2560 [dec]
VI_WIDTH_REG:           00000280 // 640 [dec]
VI_INTR_REG:            00000002 // 2 [dec]
VI_V_CURRENT_LINE_REG:  00000000
VI_TIMING_REG:          03E52239 // 65348153 [dec]
VI_V_SYNC_REG:          0000020D // 525 [dec]
VI_H_SYNC_REG:          00000C15 // 3093 [dec]
VI_LEAP_REG:            0C150C15 // 202705941 [dec]
VI_H_START_REG:         00000000
VI_V_START_REG:         002501FF // 2425343 [dec]
VI_V_BURST_REG:         000E0204 // 918020 [dec]
VI_X_SCALE_REG:         00000200 // 512 [dec]
VI_Y_SCALE_REG:         00000400 // 1024 [dec]

doing the desk work with Glide64

scale_x = 512
scale_y = 1024

fscale_x = 512/1024 = 0.5
fscale_y = 1024/2048 = 0.5

dwHStartReg = 0x00000000
dwVStartReg = 0x002501FF

hstart = 0x0000
hend = 0x0000

hend = 640/0.5 = 1024

vstart = 0x0025 = 37
vend = 0x01FF = 511

rsp.vi_width = 0.5(hend - hstart) = 1024*0.5 = 512
rsp.vi_height = 1.0126582 * 0.5(vend - start) = 0.5063291*474 ~= 240

... suggests this (240) was the native vi_height of the previous session, and that it gets updated by the plugin spec after vi_width so it was not up-to-date in this session, so that needs to be accounted for

[HatCat]

Originally Posted by haxatax

http://code.google.com/p/angrylions-...t/n64video.cpp

I know, because I have that code in my port of angrylion's RDP already (minus the C++ extensions).
The part of that code that matters is rdp_update() .

Interesting, he is using DirectDraw...just like zilmar was

It is saying the same basic thing as what Glide64 does to calculate the native resolution; I just forgot to look back to see that was an alternative way of saying it.

It should follow the same algorithm.
But how to implement it...
I wonder should I add a new dllexport ViYScaleChanged

Extend the plugin specs with the bypass.
etc., might go to bed first