Some doubts about the HiRes mode

[Near]

I'm still wondering why did they even bother with interlaced mode in-game in RPM Racing. I mean it looks good on the title screen, but like there really isn't much detail on the tracks to make it worth it... (besides, clash with the sprites - or are those sprites meant to be hi-res too?)

The interlace effect is also extremely jarring. It makes all the cars look like they're constantly splitting in half. Might look better on an actual CRT TV, never tried it there ... but it looks terrible on LCDs and in emulators.

[lidnariq]

It makes all the cars look like they're constantly splitting in half. [...] it looks terrible on LCDs and in emulators.

That's a classic symptom of bad deinterlacing.

[93143]

AFAIK sprites are always lo-res...

OK, I knew about coordinates but wasn't sure on the image data.

Sprites can be hi-res in the vertical axis in interlace mode; there's a separate bit for it in SETINI ($2133). RPM Racing apparently doesn't use it.

Horizontal hi-res is unavailable to sprites, unless (I think) the specific application you have in mind happens to work with main/sub trickery in pseudo-hires mode (most cases won't, because sprites are flattened into a layer before being sent to main/sub).

The docs seem to imply you're supposed to alternate between two sprites to achieve higher vertical resolution in interlaced mode, which I guess makes sense (at least you can double it vertically).

No, the sprites are actually drawn at half-height, with automatic line alternation. Manual alternation is only necessary to get interlaced BG graphics outside Modes 5-6. You could leave the OBJ Interlace bit off and manually alternate the sprite graphics, but you don't need to.

[Great Hierophant]

RPM Racing looks noticeably flickery and crawly on my CRT. The effect is more noticeable on some portions of the screen as opposed to others. I believe it was a poor choice to use the interlace mode for the game. For a racing game, it isn't a very fast paced game. R.C. Pro-Am, which uses a similar perspective and style runs races around RPM Racing. The flicker can get really distracting on some of the static screens, in motion the effect is not quite so bad.

While there are a lot of menu screens in RPM Racing where the mode is used with little ill-effect, in the racing portion of the game I guess it was used to give the racing backgrounds more detail, especially because the two-player split-screen is being used at all times.

[whicker]

The developers themselves realized in the end that hi-res made their job more difficult than it needed to be. Back when there were a lot of articles being written on Blizzard I remember reading as much.

The Japanese version of RPM Racing unsurprisingly doesn't use interlaced high resolution mode in the actual race, I consider this the final version of the game. Check it out if you haven't seen it before, it's a major step up graphically. You can still cheat of course.

[gdkchan]

TM/TS/TMW/TSW have exactly the same effect as they always do. Normally, games will enable the same layers on both main and sub screens. But if they enable a layer on only one of the two screens, only every other pixel from that layer will be displayed, producing a fake-transparent dithered effect. Jurassic Park and Kirby's Dreamland 3 are two games that do this.

I believe that I implemented enough of the hires mode functionality to make Jurassic Park functional. But I have a problem through. On the even frames (in game) it seems more or less correct. But on the odd frames through, the screen turns all black because the game seems to set the screen brightness (0x2100 bits 0-3) to zero. Anyone know if it have different functionality with H hires enabled?

@byuu - Thanks for the tips, I already implemented the sprite range overflow handling and will implement the OAM interlace and priority rotation (which I guess it's responsible to make the stars swing) later. It indeed have some curious tests. On the test with the Super Mario World-like scrolling background, it will test if value from a Open Bus region (0x2184 ~ 0x21FF) is equal to the last byte of the operand of the last instruction (well actually it just does a AND by 0x20, so any value with bit 5 set will do, the expected value is 0x21 iirc). Without Open Bus emulation it just keeps stuck on that part forever.

Edit:
I figured out the problem with Jurassic Park. Looks like a the CPU will continue from a WAI instruction after an IRQ occurs even if the IRQ Disable flag is set on the P register. Now it looks correct I guess.