Vertical alignment nog correct when FB emulation is switched off

[akamming]

Hi,

FB emulation has quite a performance hit for the RPI. So i wanted to switch it off. However i found out in a most of the games the vertical alignment of objects is no longer correct, making it unusable.

I put in a lot of info in this issue description, hopefully this will help fixing it:

In the normal (FB Emu on), the screen is built up like this ( i'm not an expert so i probably use incorrect terms. sorry for that. ;-) )

when FB Emu is switched off i always notice the following pattern:

1. There are no objects correctly vertically aligned. They are drawn either too far up (3) or down (4), or too big (5)
2. Horizontal alignment is always correct.
3. When objects are drawn too high up the screen, the shift up is always the same distance: The delta between Top and Virtual Top. So probably aligned to top instead of virtual top.
4. When objects are drawn too far down the screen ,the shift is also always the same distance: The delta between Bottom and Virtual bottom. So probably aligned to bottom instead of virtual bottom
5. Sometime objects are drawn relative to both virtual bottom and top making them too big
6. Due to the vertical misalignment parts of the screen are not cleared correctly, leaving old objects as garbage on the screen
7. There is an exception causing some games to run correctly: If a screen in a game has no overscan (e.g. a lot of screens in Ridge Racer 64 or Kirby Crystal Shards)). The alignment issue is gone. This is expected if my assumptions for point 3, 4 and 5 are correct: Top and virtual top (and bottom and virtual bottom) are the same, do it does not matter if Y is derived from Top or virtual top (or bottom or virtual bottom).

so my guess is the alignment of the drawing of the objects is done relative to the absolute top and bottom of the screen instead of the virtual top and bottom in the picture above.

An example with Mario Kart with Mupen64Plus with GLideN64: (can be reproduced with almost all games. Most games have this issue when FB emu is off):

This is what start of the race screen should look like (FB Emu on): but this is what it looks like with FB Emu off: As you can see this screen has all 3 problems.

• the playfield has moved up a bit (point 3 above)
• the black box which should be behind the text Luigi Runway is too far down (point 4 above)
• the text "Mushroom Cup" and "Luigi's runway" have point 5: Drawn too big

a few seconds later when the game starts:

• the game area has moved up too far
• the 2d representations of the course has moved up too far as wll
• but the car which represents your own kart in the 2d representation of the course has moved too far down

some other examples with libretro-mupenplus next 2.1, also using GLideN64: Mario Kart start screen (FB Emu on): same screen (FB Emu off): As you can see screen moved up.

Cruis'n World course select screen (FB Emu on): Same screen with FB Emu off: screen moved too far up and there is "garbage" left from previous screens with objects drawn too low, which weren't cleared correctly

Cruis'n World gameplay (FB Emu on): Same screen (FB Emy off):

• black bars below "MPH" and "AUTO", in window on the right where you can see the turns in 2d.
• The rectangle is drawn too high and or the road too low
• the 3d area is stretched too much vertically, there should be a little overscan top and bottom, but there isn'n it.

Some additional info: I reproduced the same effect in 2 emulators:

• Mupen64plus, compiled from latest source with latest GLideN64
• lr-Mupen64plus-next 2.1 compiled from source (including GLideN64)

and on 2 totally different hardware configs:

• a RPI4 (arm based with embedded graphics chip)
• and a Dell Lattitude E6320 laptop (with an embedded Intel Graphics chip).

I know i can expect some compatibility issues when switching off FB emulation, but i would not expect this alignment issue to top and bottom. so i think it 's an issue in the code. and i really hope it can be fixed. Because of the big performance hit of FB Emulation on low end devices we can make a lot users happy if this issue could be fixed because playability would increase a lot if FB emu can be switched off.

This issue was originally logged as an issue on lr mupen64plus next, but since it turned out the be in the GLideN64 i post it here. Let me know if i can do anything to help solve it.

[gonetz]

N64 has Video Interface (VI) subsystem, which maps digital image to TV screen. VI controls, how the image will be placed on screen. For example, your MK64 shots. I'm sure it is PAL version of the game. It has black bars on top and bottom because PAL has more horizontal lines than NTSC. VI adds vertical offset when it maps image to screen. Emulation of VI is part of FB emulation.

Probably it is possible to apply reduced VI emulation when FB is off. I'll check it if I will have time on it.

[akamming]

Aha. Tx! Does this also imply that this issue would not be there on ntsc versions of games? Cause for several games there are both us and europe versions. I can check some games on both pal and ntsc and see if the issue dissappears with either one.. would be a nice workaround...

[akamming]

Just did a small test with regions. This is what i noticed: Cruis'n world. Us version works fine with fb emu off. Europe version has the above mentioned issues

For mario kart iit s the other way around.

I think you are correct in your assumption that this is the issue.

1 remark: i don't own an n64 myself, so the only way to obtain roms is from sites on the internet. And i can only look at the filename to determine the region. I already found a rom which has "(usa)" in the name but turned put to be the europe version (i could language select also french, german and spanish). So is there an other way to determine the region for a rom?

[gonetz]

So is there an other way to determine the region for a rom?

You can use VI/S counter. PAL games use 50 VI/S, NTSC 60 VI/S.

[akamming]

You can use VI/S counter. PAL games use 50 VI/S, NTSC 60 VI/S.

ah..tx.! just checked and found out i cannot trust the filenaming to determin pal or ntsc. I have a romset which has a lot of files with (USA) in the filename, but only show 50 VI/S when i switch on the VI/S counter. Also some roms with (EUROPE) in the filename, but have 60 VI/S

Just did a recheck on the games which have the alignment issues and the ones which do not. Pattern is clear.

• all games with 50 VI/S have these vertical alignment issues with FB Off, games with 60 VI/S do not.
• did an extra test by downloading USA versions 2 of games which have the issues for me and indeed the alignment issue disappears on the same game if i use the USA version of the rom.

[Jj0YzL5nvJ]

So is there an other way to determine the region for a rom?

Using GoodTools (GoodName/GoodSet/GoodN64), No-Intro and/or any other, like MAME's hash. File hashes in general.

You can use VI/S counter. PAL games use 50 VI/S, NTSC 60 VI/S.

And MPAL?